Helma Logo
main list history

Helma 1.7 wishlist

Some vague feature ideas for Helma 1.7

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.


Alternative Session Implementations

Start using SessionManager to actually implement different session management schemes.

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


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


#1 by maks at 2008/01/10 01:51


  • very much in favour of point 1, as I'd like to for instance try implementing an 'alternative' builtin DB, mostly built in js not Java, so having a clean api would be great from that point of view.
  • also would very much like to see some of the deprecated code extensions being removed as at the moment its quite confusing I think for new comers.
  • I also like the idea of supporting JSAdapter, as that would make it even easier to do quite "deep" things using only js without having to resort to java. BUT will this mean having to switch over to using the rhino bundled in java6 ??? JSAdapter turns out to be just a Java class and its now added in helma 1.6.2 in package helma.scripting.rhino
  • I don't see mention of your proposed 'Query' collections - does that meant they are no longer in favour? (I for one would be very keen to see them in 1.7)
  • actually very happy with all your other proposals listed here so far.
  • Also is proposing using JSON as an alternative format for config file to radical for 1.7 ? If so I would propose it for 2.0 instead
#2 by Philipp at 2008/04/08 16:17

A huge improvement would be a better documentation. It's impossible to get a "quick" overview over Helma and it's features. If you see some advanced source at work it's really hard to understand what's going on.

Maybe this point is a nice job for a "HTL-Diplomarbeit" or bachelor thesis. I know some really good HTL examples from the past, but I've no idea how it's today.

#3 by maks at 2008/04/09 03:07

As a first step to decoupling the Persistence API (which I do think is a fantastic idea) could be to implement http://helma.org/bugs/show_bug.cgi?id=612
which should then allow new persistence schemes to be "tried out" in pure js.