Helma Logo
main list history
previous version  overview  next version

Version 15 by hannes on 24. April 2008, 00:46

Helma NG 0.2 is the next version of *Helma NG* and scheduled for release in May 2008.

=== Features already implemented

* Low level skin support, and support for skin parsing and rendering. Low level skin parsing will use a callback based approach. The parseSkin() function will take two arguments: the name of the skin resource and a javascript function that will be called with the skin parts as arguments as they are parsed. It is expected that modules that implement skin rendering functionality build on top of this low level API to provide more abstraction.
* helma.skin module implementing basic helma 1 skin functionality, subskins and *skin inheritance|http://dev.helma.org/wiki/Helma+1.7+feature+scratchpad/#Allowskinstoextendinheritfromeachother*.
* *JSAdapter* support for modules. Just define any of the following functions, and the module will behave accordingly.
* Support for continuations. Needs to be started with with -Drhino.optlevel=-1 though.

=== Planned features (work in progress)

* A modules module that provides meta information about loaded modules. In addition to an overview of loaded modules, currently I think we'll need the following:
** modules.name - the name of the current module
** modules.path - the path of the current module relative to the 'root' module (for href generation in simpleweb)
** modules.parent - a reference to the module that loaded the current module (for relative resource paths in skin loading)
** maybe a way to retrieve the file system path of the module, but I think getResource() covers this already.
* A logging module. should we keep helma logging?
* Static file serving with the development server.
* Port over more modules from Helma 1.
* Move over rhino serialization code from helma 1.

=== Ideas, Dreams, Feature requests (feel free to add your own)

* Rethink the module namespace. Does very generic stuff such as File IO need the 'helma' prefix? (hns)
* Allow modules to define which properties to export, and keep the others private? This would again require some sort of wrapping.
* Support for running web server and shell simultaneously, running compiled and interpreted code in the same app, and launching the debugger in running apps.
* Include gobi markuplib as module?
* Make module for functional programming utils contiaing partial() from gobi markuplib. Check with functional programming pundits for what else to include.