Helma Logo
main list history

Version 18 by hannes on 04. April 2009, 09:42

10* Logical next step would be to bring those two together and "re-conventionalize" automatic root object lookup
20Status: nothing so far. What we could possibly do is implement HopObject persistence for session nodes (mapping to a Session object).
29
30=== Sort out macro resolver problems
31
32Solve macro resolver problems introduced with the *fix for bug 617|http://helma.org/bugs/show_bug.cgi?id=617*. Discussion thread is *over here|http://groups.google.com/group/helma/browse_frm/thread/b15805fd6f661d64*.

Version 17 by hannes on 02. April 2009, 13:38

27Status: Still trying to come *come up with a syntax for this this|http://helma.pastebin.com/f2ffec49* that is neither ugly nor breaks existing code.

Version 16 by hannes on 02. April 2009, 12:00

9* *Programmatically defined HopObject mappings|http://dev.helma.org/wiki/New+features+in+Helma+1.7/#ProgrammaticallydefinedHopObjectmappings*mappings|Defining HopObject mappings programmatically*

Version 15 by simono on 02. April 2009, 11:31

32* Url.js that parses all fields (rfc3986) and allows to set them. examples: *python like urlparser|http://snipplr.com/view/10139/urlparse--pythonlike-url-parser-and-manipulator/* or *minimalistic parseUri|http://blog.stevenlevithan.com/archives/parseuri*
33

Version 14 by hannes on 02. April 2009, 11:17

3=== New Persistence API implemented in JavaScriptDecouple Objectmodel API
7Status:
8* *HopObject-less Helma applications|http://groups.google.com/group/helma/browse_frm/thread/fc079ea32378a1db/c57991bca6c4c331?lnk=gst&q=pure+javascript#c57991bca6c4c331*
9* *Programmatically defined HopObject mappings|http://dev.helma.org/wiki/New+features+in+Helma+1.7/#ProgrammaticallydefinedHopObjectmappings*
10
16Status: nothing so far
17
23What about syntax? Currently I sympathise with the idea Status: Still trying to change subskin syntax from <code><% #subskinname %></code> to <code><% #subskin subskinname %></code> - in other words add come up with 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 <code><% #extends superskinname %></code>. Going further on this, it might be possible to implement an API for meta-macros (for lack of a better expression) this that allow low level manipulation of skins, subskins and macrosis neither ugly nor breaks existing code.
25The old <code><% #subskin %></code> syntax would be deprecated but supported for the indefinite future.
26
31Status:
32* Some work done on *helma.File|http://dev.helma.org/bugs/show_bug.cgi?id=636* and *helma.Mail|http://dev.helma.org/bugs/show_bug.cgi?id=540*.
33* No decision yet on removal of core extensions.
34
35
36Status: pending due to performance considerations regarding java varchar.

Version 13 by hannes on 19. February 2009, 12:21

Version 12 by hannes on 14. April 2008, 19:22

19The subskins feature *introduced in Helma 1.6|new skin features 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.

Version 11 by hannes on 14. April 2008, 19:12

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

Version 10 by hannes on 14. April 2008, 19:11

17This is a very useful idea to take from *Django|http://www.djangoproject.com/documentation/templates/*. Extending This allows developers to create a skin would have base.html template with the same effect as partially overriding a skin from another repository: Some subkins may be overriddenshared XHtml boilerplate code, and let sub-templates fill in the others are inherited from the base skinactual content. 
19What about syntax? The natural thing subskins feature *introduced in Helma 1.6|new skin features 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 to just use <code><% extends foo %></code>overridden, but that would clash with ordinary macros. Maybe borrow the # others are inherited from subskins and use <code><% #extends foo %></code>?the base skin.
20
21What about syntax? Currently I sympathise with the idea to change subskin syntax from <code><% #subskinname %></code> to <code><% #subskin subskinname %></code> - 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 <code><% #extends superskinname %></code>. 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.

Version 9 by hannes on 14. April 2008, 10:36

15=== Allow skins to extend/inherit from each other
16
17This is a very useful idea to take from *Django|http://www.djangoproject.com/documentation/templates/*. Extending a skin would have the same effect as partially overriding a skin from another repository: Some subkins may be overridden, the others are inherited from the base skin.
18
19What about syntax? The natural thing would be to just use <code><% extends foo %></code>, but that would clash with ordinary macros. Maybe borrow the # from subskins and use <code><% #extends foo %></code>?
20

Version 8 by hannes on 08. April 2008, 15:24

20=== Varargs Support for res.write() and consorts
21
22Allow 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.
23
26* varargs support for res.write(), res.writeln(), res.debug(): pass 0..n arguments to these methods, they will be rendered speparated by a single whitespace like print in python.

Version 7 by hannes on 08. April 2008, 11:34

3* 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 New Persistence API implemented in stand-alone/explicit fashion.JavaScript
4* Start using SessionManager to actually implement different session management schemes (db persistence etc)
5Try 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.
6
7=== Alternative Session Implementations
8
9Start using SessionManager to actually implement different session management schemes.
10
11* db persistence
12* client based persistence
13* replication/load balancing
14
15=== Library and Modules
16
6* Drop helma.doc package, maybe in favour of jsdoc-toolkit, or get token parsing funcitonality accepted into rhino cvs.
7=== More Ideas
8
9* Support <strike>Support *JSAdapter|http://blogs.sun.com/sundararajan/entry/self_javascript_and_jsadapter*com/sundararajan/entry/self_javascript_and_jsadapter*</strike> already in helma 1.6.
12* Rewrite helmadoc to rewrite with standard rhino (no more token patch).
13* Drop helma.doc package, maybe in favour of jsdoc-toolkit, or get token parsing funcitonality accepted into rhino cvs.

Version 6 by hannes on 04. April 2008, 15:09

14* Debian/Ubuntu package for Helma

Version 5 by hannes on 04. April 2008, 12:46

12* allow apps.properties extensions to be defined in app.properties (without the "appname." prefix)
13* Rewrite helmadoc to rewrite with standard rhino (no more token patch).

Version 4 by hannes on 02. April 2008, 15:41

11* varargs support for res.write(), res.writeln(), res.debug(): pass 0..n arguments to these methods, they will be rendered speparated by a single whitespace like print in python.

Version 3 by hannes on 08. January 2008, 17:08

9* Support *Jürg Lehni's rhino extensions|https://dev.scriptographer.com/*
10* Support *JSAdapter|http://blogs.sun.com/sundararajan/entry/self_javascript_and_jsadapter*

Version 2 by hannes on 08. January 2008, 15:48

8* Provide full configurability when running Helma in embedded (tomcat) mode.

Version 1 by hannes on 08. January 2008, 15:47

1Some vague feature ideas for Helma 1.7
3* 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.
4* Start using SessionManager to actually implement different session management schemes (db persistence etc)
5* Extend and enhance helma.File.js and other modules
6* Start removing core extensions in favor of modules?
7* Drop helma.doc package, maybe in favour of jsdoc-toolkit, or get token parsing funcitonality accepted into rhino cvs.