Helma

The helma.system module provides methods to access the Helma NG scripting engine. Contents [hide]Command line argumentsSandboxesRepositories and ResourcesHost ObjectsExtending Java ClassesSetting the Optimization LevelGoing further Command line ... [More] arguments Command line arguments passed to the main script can be accessed through the args property of the helma.system module. This is currently an instance of an unmodifiable java.util.List, althought we may expose this as JavaScript array in the future. Sandboxes One cool new feature the helma.system module provides is the createSandbox() function to create JavaScript sandboxes. It allows you to set up an isolated JavaScript environment with its own module search path and global object. Optionally, you can inject global properties, restrict access to Java objects using a ClassShutter, and seal the global object. Repositories and Resources FIXME: addRepository(), getRepositories() Host Objects By default, Helma NG does not contain any custom host objects. This makes sense when using Helma NG in other contexts than the typical web application. You can also register your own host objects using the helma.system.addHostObject() method, passing the host object java class as only argument. Extending Java Classes Helma NG allows you to add methods and properties to existing Java classes. The helma.system.extendJavaClass() takes a java class as argument and returns an extended java class wrapper. You can add Javascript functions to the java class like it was a Javascript constructor, using the class wrapper's prototype property. var HashMap = helma.system.extendJavaClass(java.util.HashMap); HashMap.prototype.dump = function() { res.write(this); } Note that while the class wrapper works as constructor for the extended class, the added functions and properties are available also on objects created using the standard java constructor and even objects created and returned from java code. The Helma NG object wrapper takes care of this. Note that this is different from Rhino's JavaAdapter. JavaAdapter allows you to create new java classes in javascript, extending existing classes and implementing existing interfaces. The Helma NG java class extension feature allows you to add scripted functions to existing java classes without creating a new class. You can also script java superclasses and interfaces. However, Helma NG currently does not implement extended class merging or chaining. In other words, if both java.util.HashMap, java.util.Map and java.lang.Object classes are extended, java instances will only have the "nearest" extension: HashMap instances will only have the extended properties of java.util.HashMap, TreeMap objects those of java.util.Map, and ArrayList those of java.lang.Object. Setting the Optimization Level The helma.system.setRhinoOptimizationLevel() method allows you to set the Rhino optimization level. Accepted values are integer numbers between -1 and 9. The default level is 0 and implements basic Javascript to Java bytecode compilation. Level -1 disables the bytecode compiler and sets Rhino to interpreter mode, which is required for some features such as continuations. Levels 1 to 9 add some optimizations that may or may not be detrimental to your health. Note that Helma NG can run in both Java-compiled and interpreted mode in the same application, so you can call this on a per-request basis in the onInvoke callback. Also note that setting the optimization level in the 0..9 range does not cause scripts that have already been compiled and cached to be recompiled. Going further The system module provides utility methods getRhinoContext() and getRhinoEngine() to access the current Rhino Context and Rhino Engine instances. These classes provide a lot of Javascript related functionality that can be easily used from application code. [Less]

One cool new feature the helma.system module provides is the createSandbox() function to create JavaScript sandboxes. It allows you to set up an isolated JavaScript environment with its own module search path and global object. Optionally, you can ... [More] inject global properties, restrict access to Java objects using a ClassShutter, and seal the global object. The following code shows how to set up a sandbox with the directory some/dir as only module path and pass it the require() function from our host environment: include("helma/system"); var sandbox = createSandbox("some/dir", {require: require}); sandbox.runScript("test.js"); The createSandbox() function tries to evaluate a file called global.js to initialize the sandbox's global object. Optionally, the global object can be sealed after global.js has been run. The following code shows how to do that and also creates a sandbox that prevents any access to java objects. var classShutter = function(classname) { return false; }; var sandbox = createSandbox('some/dir', {require: require}, classShutter, true); Note that the require function we pass to the sandbox is not affected by the ClassShutter since it is defined in the outer trusted host environment. [Less]

This is a wiki space dedicated to Helma NG. Feel free to create new pages or edit existing ones. Contents [hide]ResourcesMain areasRecently edited pages Resources Mailing listTrac/RoadmapTrac/IssuesSource CodeSubversion: Browse, CheckoutGit ... [More] (Github) Main areas JavaScript RuntimeModulesWeb Framework and MiddlewarePersistence APITools Recently edited pages namemodified bylast modifiedSandboxeshannes2009/04/03 18:19helma.systemhannes2009/04/03 18:19helma.filestorehannes2009/02/20 23:00Persistence APIhannes2009/02/20 22:59Web Frameworkhannes2009/02/20 20:26Middlewarehannes2009/02/20 20:07moduleshannes2009/02/17 16:31JavaScript Runtimehannes2009/02/06 11:12Toolshannes2009/02/06 10:23Modules and Scopeshannes2009/01/30 16:08Metamethodshannes2008/10/15 00:41New Regexp based URL dispatchinghannes2008/09/26 22:46Differences between Helma 1 and Helma NGanton2008/09/25 21:45Ideashannes2008/09/25 17:00helma.unittesthannes2008/09/05 16:25Plugin Manager Modulehannes2008/06/07 22:56helma.skinhannes2008/05/26 12:22Release 0.2hannes2008/05/24 21:32Background and Historyrobert.thurnher2008/05/24 20:18core.datehannes2008/05/21 23:55 [Less]

Some vague feature ideas for Helma 1.7 Contents [hide]Decouple Objectmodel APIAlternative Session ImplementationsAllow skins to extend/inherit from each otherSort out macro resolver problemsLibrary and ModulesVarargs Support for res.write() and ... [More] consortsMore Ideas Decouple Objectmodel API Try to decouple helma.objectmodel from the rest of the framework, and start layering a javascript interface on top of it so it can be used in stand-alone/explicit fashion. Status: HopObject-less Helma applicationsProgrammatically defined HopObject mappingsLogical next step would be to bring those two together and "re-conventionalize" automatic root object lookup Alternative Session Implementations Start using SessionManager to actually implement different session management schemes. db persistenceclient based persistencereplication/load balancing Status: nothing so far. What we could possibly do is implement HopObject persistence for session nodes (mapping to a Session object). Allow skins to extend/inherit from each other This is a very useful idea to take from Django. This allows developers to create a base.html template with the shared XHtml boilerplate code, and let sub-templates fill in the actual content. The subskins feature introduced in Helma 1.6 are a perfect fit for this. Extending a skin would have the same effect as partially overriding a skin from another repository: Some subkins may be overridden, the others (and usually the main skin) are inherited from the base skin. Status: Still trying to come up with a syntax for this that is neither ugly nor breaks existing code. Sort out macro resolver problems Solve macro resolver problems introduced with the fix for bug 617. Discussion thread is over here. Library and Modules Extend and enhance helma.File.js and other modulesUrl.js that parses all fields (rfc3986) and allows to set them. examples: python like urlparser or minimalistic parseUri Start removing core extensions in favor of modules? Status: Some work done on helma.File and helma.Mail.No decision yet on removal of core extensions. Varargs Support for res.write() and consorts Allow to pass 0..n arguments to res.write(), res.writeln(), res.debug() and similar methods. My proposal is to write out arguments separated by a single whitespace like print does in python. Status: pending due to performance considerations regarding java varchar. More Ideas Provide full configurability when running Helma in embedded (tomcat) mode.Support Jürg Lehni's rhino extensionsSupport JSAdapter already in helma 1.6.2allow apps.properties extensions to be defined in app.properties (without the "appname." prefix)Rewrite helmadoc to rewrite with standard rhino (no more token patch)Drop helma.doc package, maybe in favour of jsdoc-toolkit, or get token parsing funcitonality accepted into rhino cvs.Debian/Ubuntu package for Helma [Less]

Helma svn trunk has a new global function called definePrototype that allows to define Hopobject database mappings from JavaScript: A few notes/caveats: You can call definePrototype() on existing prototypes, and you can update an existing ... [More] prototype's mapping at runtime.Defining database mappings via properties files and JavaScript code is mutually exclusive. In other words, if you use definePrototype() on a prototype that also has one or more type.properties files, those properties files will be ignored. This is intentional. Defining a new (previously not existing) prototype via definePrototype() from the code in another prototype directory other than Global will likely throw an exception.definePrototype() currently has very limited support for dependency tracking. If the type mapping refers to another prototype that hasn't been defined yet, that mapping will probably throw an exception or be borked. It is therefore advisable to define all prototypes in one place/file. A working mapping for Gobi looks like this: definePrototype("Page",{ _db: "gobi", _table: "page", _id: "id", _name: "name", _parent: "parent, parent.version_history, parent.comment_pages, parent.embedded_pages", _prototype: "prototype", name: "name", body: "body", prototype: "prototype", weight: "weight", groupname: "groupname", formdata: "formdata", permissions: "permissions", attachments: "attachments", childtype: "childtype", collection: "collection", createtime: "createtime", modifytime: "modifytime", serialId: "serialId", parent: { object: "Page", local: "parent_id", foreign: "id" }, _children: { collection: "Page", accessname: "name", local: "id", foreign: "parent_id", filter: "collection = 'main'", order: "weight, createtime", cachemode: "aggressive" }, version_history: { collection: "Page", local: "id", foreign: "parent_id", filter: "collection = 'history'", order: "createtime" }, comment_pages: { collection: "Page", local: "id", foreign: "parent_id", filter: "collection = 'comment'", order: "createtime" }, embedded_pages: { collection: "Page", local: "id", foreign: "parent_id", filter: "collection = 'embedded'", order: "createtime" }, links_in: { collection: "Link", local: "id", foreign: "target_id", group: "type", "group.order": "id, createtime", order: "id, createtime", accessname: "sourceId", cachemode: "aggressive", loadmode: "aggressive" }, links_out: { collection: "Link", local: "id", foreign: "source_id", group: "type", "group.order": "id, createtime", order: "id, createtime", accessname: "targetId", cachemode: "aggressive", loadmode: "aggressive" }, form: { object: "Type", local: "form_id", foreign: "id" }, childform: { object: "Type", local: "childform_id", foreign: "id" }, creator: { object: "Page", local: "creator_id", foreign: "id" }, modifier: { object: "Page", local: "modifier_id", foreign: "id" } }); definePrototype("AdminPage", { _extends: "Page" }); definePrototype("Type", { _extends: "AdminPage" }); definePrototype("Link", { _db: "gobi", _table: "link", _id: "id", sourceId: "source_id", targetId: "target_id", createtime: "createtime", modifytime: "modifytime", type: "type", info: "info", serialId: "serial_id", source: { object: "Page", local: "source_id", foreign: "id" }, target: { object: "Page", local: "target_id", foreign: "id" } }); [Less]

Some vague feature ideas for Helma 1.7 Contents [hide]Decouple Objectmodel APIAlternative Session ImplementationsAllow skins to extend/inherit from each otherLibrary and ModulesVarargs Support for res.write() and consortsMore Ideas Decouple ... [More] Objectmodel API Try to decouple helma.objectmodel from the rest of the framework, and start layering a javascript interface on top of it so it can be used in stand-alone/explicit fashion. Status: HopObject-less Helma applicationsProgrammatically defined HopObject mappings Alternative Session Implementations Start using SessionManager to actually implement different session management schemes. db persistenceclient based persistencereplication/load balancing Status: nothing so far Allow skins to extend/inherit from each other This is a very useful idea to take from Django. This allows developers to create a base.html template with the shared XHtml boilerplate code, and let sub-templates fill in the actual content. The subskins feature introduced in Helma 1.6 are a perfect fit for this. Extending a skin would have the same effect as partially overriding a skin from another repository: Some subkins may be overridden, the others (and usually the main skin) are inherited from the base skin. Status: Still trying to come up with a syntax for this that is neither ugly nor breaks existing code. Library and Modules Extend and enhance helma.File.js and other modulesUrl.js that parses all fields (rfc3986) and allows to set them. examples: python like urlparser or minimalistic parseUri Start removing core extensions in favor of modules? Status: Some work done on helma.File and helma.Mail.No decision yet on removal of core extensions. Varargs Support for res.write() and consorts Allow to pass 0..n arguments to res.write(), res.writeln(), res.debug() and similar methods. My proposal is to write out arguments separated by a single whitespace like print does in python. Status: pending due to performance considerations regarding java varchar. More Ideas Provide full configurability when running Helma in embedded (tomcat) mode.Support Jürg Lehni's rhino extensionsSupport JSAdapter already in helma 1.6.2allow apps.properties extensions to be defined in app.properties (without the "appname." prefix)Rewrite helmadoc to rewrite with standard rhino (no more token patch)Drop helma.doc package, maybe in favour of jsdoc-toolkit, or get token parsing funcitonality accepted into rhino cvs.Debian/Ubuntu package for Helma [Less]

This page docuents new features in Helma 1.7. As Helma 1.7 hasn't been released yet, this page is incomplete and work-in-progress. Contents [hide]Case sensitive HopObject property namesProgrammatically generated collectionsProgrammatically defined ... [More] HopObject mappingsApache Commons Daemon support Case sensitive HopObject property names Property names in HopObjects are now case sensitive. This means that obj.foo, obj.Foo and obj.FOO no longer point to the same property. This feature should help to enforce good programming habits and speed up property access. Programmatically generated collections Helma 1.7 defines a new static method on HopObject constructors that allows to generate HopObject collections via JavaScript. The method is called HopObject.getCollection() and takes a single JavaScript object as argument. It returns a HopObject that is equivalent to the one you would get by defining it as a collection in a type.properties file. Programmatically defined HopObject mappings There is a new and experimental definePrototype function that allows to define prototype mappings via JavaScript. In its current implementation, there is a global function called definePrototype() that takes two arguments: The prototype name, and a JavaScript object describing the type mapping. Apache Commons Daemon support Helma 1.7 introduces Apache Commons Daemon support, making it possible to run the embedded Jetty server on port 80 for ordinary users on Unix and running Helma as service on Unix and Windows systems. There also is a Debian/Ubuntu package that indorses Commons Daemon jsvc utility to install Helma as service. [Less]

This page docuents new features in Helma 1.7. As Helma 1.7 hasn't been released yet, this page is incomplete and work-in-progress. Contents [hide]Case sensitive HopObject property namesProgrammatically generated collectionsProgrammatically defined ... [More] HopObject mappings Case sensitive HopObject property names Property names in HopObjects are now case sensitive. This means that obj.foo, obj.Foo and obj.FOO no longer point to the same property. This feature should help to enforce good programming habits and speed up property access. Programmatically generated collections Helma 1.7 defines a new static method on HopObject constructors that allows to generate HopObject collections via JavaScript. The method is called HopObject.getCollection() and takes a single JavaScript object as argument. It returns a HopObject that is equivalent to the one you would get by defining it as a collection in a type.properties file. Programmatically defined HopObject mappings There is a new and experimental definePrototype function that allows to define prototype mappings via JavaScript. In its current implementation, there is a global function called definePrototype() that takes two arguments: The prototype name, and a JavaScript object describing the type mapping. [Less]

Some vague feature ideas for Helma 1.7 Contents [hide]Decouple Objectmodel APIAlternative Session ImplementationsAllow skins to extend/inherit from each otherLibrary and ModulesVarargs Support for res.write() and consortsMore Ideas Decouple ... [More] Objectmodel API Try to decouple helma.objectmodel from the rest of the framework, and start layering a javascript interface on top of it so it can be used in stand-alone/explicit fashion. Status: HopObject-less Helma applicationsProgrammatically defined HopObject mappings Alternative Session Implementations Start using SessionManager to actually implement different session management schemes. db persistenceclient based persistencereplication/load balancing Status: nothing so far Allow skins to extend/inherit from each other This is a very useful idea to take from Django. This allows developers to create a base.html template with the shared XHtml boilerplate code, and let sub-templates fill in the actual content. The subskins feature introduced in Helma 1.6 are a perfect fit for this. Extending a skin would have the same effect as partially overriding a skin from another repository: Some subkins may be overridden, the others (and usually the main skin) are inherited from the base skin. Status: Still trying to come up with a syntax for this that is neither ugly nor breaks existing code. Library and Modules Extend and enhance helma.File.js and other modulesUrl.js that parses all fields (rfc3986) and allows to set them. examples: python like urlparser or minimalistic parseUri Start removing core extensions in favor of modules? Status: Some work done on helma.File and helma.Mail.No decision yet on removal of core extensions. Varargs Support for res.write() and consorts Allow to pass 0..n arguments to res.write(), res.writeln(), res.debug() and similar methods. My proposal is to write out arguments separated by a single whitespace like print does in python. Status: pending due to performance considerations regarding java varchar. More Ideas Provide full configurability when running Helma in embedded (tomcat) mode.Support Jürg Lehni's rhino extensionsSupport JSAdapter already in helma 1.6.2allow apps.properties extensions to be defined in app.properties (without the "appname." prefix)Rewrite helmadoc to rewrite with standard rhino (no more token patch)Drop helma.doc package, maybe in favour of jsdoc-toolkit, or get token parsing funcitonality accepted into rhino cvs.Debian/Ubuntu package for Helma [Less]

Helma svn trunk has a new global function called definePrototype that allows to define Hopobject database mappings from JavaScript: A few notes/caveats: You can call definePrototype() on existing prototypes, and you can update an existing ... [More] prototype's mapping at runtime.Defining database mappings via properties files and JavaScript code is mutually exclusive. In other words, if you use definePrototype() on a prototype that also has one or more type.properties files, those properties files will be ignored. This is intentional. Defining a new (previously not existing) prototype via definePrototype() from the code in another prototype directory other than Global will likely throw an exception.definePrototype() currently has very limited support for dependency tracking. If the type mapping refers to another prototype that hasn't been defined yet, that mapping will probably throw an exception or be borked. It is therefore advisable to define all prototypes in one place/file. A working mapping for Gobi looks like this: definePrototype("Page", { _db: "gobi", _table: "page", _id: "id", _name: "name", _parent: "parent, parent.version_history, parent.comment_pages, parent.embedded_pages", _prototype: "prototype", name: "name", body: "body", prototype: "prototype", weight: "weight", groupname: "groupname", formdata: "formdata", permissions: "permissions", attachments: "attachments", childtype: "childtype", collection: "collection", createtime: "createtime", modifytime: "modifytime", serialId: "serialId", parent: { object: "Page", local: "parent_id", foreign: "id" }, _children: { collection: "Page", accessname: "name", local: "id", foreign: "parent_id", filter: "collection = 'main'", order: "weight, createtime", cachemode: "aggressive" }, version_history: { collection: "Page", local: "id", foreign: "parent_id", filter: "collection = 'history'", order: "createtime" }, comment_pages: { collection: "Page", local: "id", foreign: "parent_id", filter: "collection = 'comment'", order: "createtime" }, embedded_pages: { collection: "Page", local: "id", foreign: "parent_id", filter: "collection = 'embedded'", order: "createtime" }, links_in: { collection: "Link", local: "id", foreign: "target_id", group: "type", "group.order": "id, createtime", order: "id, createtime", accessname: "sourceId", cachemode: "aggressive", loadmode: "aggressive" }, links_out: { collection: "Link", local: "id", foreign: "source_id", group: "type", "group.order": "id, createtime", order: "id, createtime", accessname: "targetId", cachemode: "aggressive", loadmode: "aggressive" }, form: { object: "Type", local: "form_id", foreign: "id" }, childform: { object: "Type", local: "childform_id", foreign: "id" }, creator: { object: "Page", local: "creator_id", foreign: "id" }, modifier: { object: "Page", local: "modifier_id", foreign: "id" } }); definePrototype("AdminPage", { _extends: "Page" }); definePrototype("Type", { _extends: "AdminPage" }); definePrototype("Link", { _db: "gobi", _table: "link", _id: "id", sourceId: "source_id", targetId: "target_id", createtime: "createtime", modifytime: "modifytime", type: "type", info: "info", serialId: "serial_id", source: { object: "Page", local: "source_id", foreign: "id" }, target: { object: "Page", local: "target_id", foreign: "id" } }); [Less]