Helma in a Nutshell
Philip Weaver created this document on November 19, 2007. This is a private rough draft. It is intended to cover Helma 1.6. I intend to describe getting up and running with Helma very concisely and quickly and I intend to present many simple statements of fact. I intend to initially focus on using the internal XML database, explain how HopObjects work in relation to page requests and in relation to data persistence in the internal database, explain the workings of the properties files, explain conventions, etc. And more. If there are areas where the documentation is already obvious or sufficient or it is a non-core feature, I may link: such as skins, macros, etc.
Questions (I'm new to Helma so some of these may be misguided):
Can each session have it's own Root object? Answer: each session has their own User object which is connected to root.
If a create a new prototype directory - how does that all get wired to root? Is it automatic? (yes?) Is it via type-properties? Only via type properties?
Note: The HopObject directory extends the HopObject prototype.
Main.hac is always the default entry action
What happens if an action and a child HopObject have the same name? Does the former action get priority/override the main action of the child HopObject?
When do you have JS code in an actual JS file instead of in an hac action file? And why? A: For shared code. Only put in actions what is local to that action.
intro.applications maps to intro/applications and why? Will intro/applications also map to intro/applications?
Notes: if you add a new HopObject to an already persisted HopObject, that new HopObject will persist automatically. However, it you update the values of a HopObject, you must call persist().
I read this document: http://helma.org/docs/guide/introductions/hopobjects/
and I'm sorry but it really tells me nothing. :-) We need more concrete verbiage about what in the heck are HopObjects.
Key: Every token of a URL separated with a slash has a backing object: a HopObject
Fact from http://helma.org/docs/guide/introductions/prototypes/
"Every directory that you create inside your application's code repository becomes automatically a prototype by that name and will inherit the methods, actions, macros and skins that the HopObject prototype provides."
Worthy addition here maybe: point out that the HopObject tree is always assembled in code and that the directory structure of the prototypes has no bearing on URL resolution.
What is meant by "the methods, actions, macros and skins that the HopObject prototype provides?"
Phil's note: so does this indeed mean that a HopObject directory extends the basic HopObject prototype?
What if instead I wanted to extend HopObject in code? And why would I ever want to do that?
This looks important: http://dev.helma.org/wiki/Config+in+Code/
Does it jive with Helma 1.6 or just 2.0? Ah it does appear to be tagged with Helma 2.
Code snippets: in the code snippets area, we need more basic examples.