helma.org/wiki/Helma 1.7 wishlist

Version 18

hannes — Sat, 04 Apr 2009 09:42:07 +0000

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

hannes — Thu, 02 Apr 2009 13:38:26 +0000

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

hannes — Thu, 02 Apr 2009 12:00:20 +0000

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

Version 15

simono — Thu, 02 Apr 2009 11:31:24 +0000

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

hannes — Thu, 02 Apr 2009 11:17:27 +0000

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

hannes — Thu, 19 Feb 2009 12:21:20 +0000

Changed tags to helma 1.7, wishlist

Version 12

hannes — Mon, 14 Apr 2008 19:22:29 +0000

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

hannes — Mon, 14 Apr 2008 19:12:46 +0000

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

Version 10

hannes — Mon, 14 Apr 2008 19:11:25 +0000

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

hannes — Mon, 14 Apr 2008 10:36:51 +0000

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

hannes — Tue, 08 Apr 2008 15:24:19 +0000

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

hannes — Tue, 08 Apr 2008 11:34:58 +0000

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_jsadaptercom/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

hannes — Fri, 04 Apr 2008 15:09:00 +0000

14	* Debian/Ubuntu package for Helma

Version 5

hannes — Fri, 04 Apr 2008 12:46:40 +0000

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

hannes — Wed, 02 Apr 2008 15:41:08 +0000

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

hannes — Tue, 08 Jan 2008 17:08:42 +0000

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

hannes — Tue, 08 Jan 2008 15:48:44 +0000

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

Version 1

hannes — Tue, 08 Jan 2008 15:47:47 +0000

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.