Helma logo
main list history

Helma 1.7 feature scratchpad

Some vague feature ideas for Helma 1.7

New Persistence API implemented in JavaScript

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.

  • db persistence
  • client based persistence
  • replication/load balancing

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.

What about syntax? Currently I sympathise with the idea to change subskin syntax from <% #subskinname %> to <% #subskin subskinname %> - in other words add a #subskin keyword. This would have two benefits: first it makes subskin syntax more self-explanatory, second it would make place for other "meta-macros" like <% #extends superskinname %>. Going further on this, it might be possible to implement an API for meta-macros (for lack of a better expression) that allow low level manipulation of skins, subskins and macros.

The old <% #subskin %> syntax would be deprecated but supported for the indefinite future.

Library and Modules

  • Extend and enhance helma.File.js and other modules
  • Start removing core extensions in favor of 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.

More Ideas

  • Provide full configurability when running Helma in embedded (tomcat) mode.
  • Support Jürg Lehni's rhino extensions
  • Support JSAdapter already in helma 1.6.2
  • allow 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

Comments

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

Hannes,

  • 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.