RSS feed for site updates
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 |
| 20 | Status: 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 | |
| 32 | Solve 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
| 27 | Status: 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 |
| 7 | Status: |
| 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 | |
| 16 | Status: nothing so far |
| 17 | |
| 23 | What 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. |
| 25 | The old <code><% #subskin %></code> syntax would be deprecated but supported for the indefinite future. |
| 26 | |
| 31 | Status: |
| 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 | |
| 36 | Status: pending due to performance considerations regarding java varchar. |
Version 13 by hannes on 19. February 2009, 12:21
- Changed tags to helma 1.7, wishlist
Version 12 by hannes on 14. April 2008, 19:22
| 19 | The 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
| 23 | The 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
| 17 | This 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. |
| 19 | What 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 | |
| 21 | What 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 | |
| 17 | This 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 | |
| 19 | What 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 | |
| 22 | 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. |
| 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) |
| 5 | 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. |
| 6 | |
| 7 | === Alternative Session Implementations |
| 8 | |
| 9 | Start 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
- Set tags to helma 1.7
| 1 | Some 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. |