Helma Logo
main list history

Version 22 by hannes on 17. February 2009, 20:16

Version 21 by tobi on 14. December 2008, 12:39

49* +1 if this means jailing access to one application/context and/or limiting access to Java classes – I assume this is necessary to provide anything similar to AppJet? (*tobi*)
50

Version 20 by oleg on 02. December 2008, 13:28

12* filestore (already implemented, in trunk)
13* CouchDB (work in progress), see *here|http://helma.pastebin.com/m496d0bf9* and *here|http://helma.pastebin.com/m332a3c45*
14* JPA - Hibernate version *already implemented|http://github.com/robi42/dbstore/tree/master*, needs to be ported<
15* Google Gears, see *Trimpath Junction|http://code.google.com/p/trimpath/wiki/TrimJunction* for reference
16
36
37==== browser based code editor a la AppJet ====
38
39* see an editor we could use *here|http://marijn.haverbeke.nl/codemirror/jstest.html*
40
41==== Comet/Java NIO support ====
42
43==== Rhino "sandboxing" ====
44
45==== Ability to import AppJet libs as Helma modules ====
46
47* tied in with module repository
48* so we can leverage the existing code base
49
50==== Dynamic tag libraries ====
51
52* like in *Grails|http://grails.org/Dynamic+Tag+Libraries*
53* ... other features from Grails? (e.g. better client side jscript lib integration)
54

Version 19 by robert on 04. June 2008, 22:33

14already working on it // *robert*

Version 18 by matthias on 04. June 2008, 08:53

24+1 /matthias
29-> see sandbox/aida/modules/aida/routing.js
33i would see this later in the roadmap /matthias

Version 17 by robert.thurnher on 25. May 2008, 04:24

26Currently helma.simpleweb uses implicit web path resolution via JavaScript properties. Well, already people are starting to ask how to trick their non-JS model domain to make this work with the URLs they want. I think we should just go with some regular expression -> method URL dispatching/registry scheme like virtually every other web framework these days. /hannes +1 // robert.thurnher/hannes
27+1 // robert.thurnher

Version 16 by robert.thurnher on 25. May 2008, 04:23

26Currently helma.simpleweb uses implicit web path resolution via JavaScript properties. Well, already people are starting to ask how to trick their non-JS model domain to make this work with the URLs they want. I think we should just go with some regular expression -> method URL dispatching/registry scheme like virtually every other web framework these days. /hannes/hannes +1 // robert.thurnher

Version 15 by Walter on 24. May 2008, 14:51

28

Version 14 by Walter on 24. May 2008, 14:51

29==== Module repository ====
30Provide some sort of automated repository for modules. For instance like the one for Wordpress: http://wordpress.org/extend/plugins/about/  // walter

Version 13 by hannes on 24. May 2008, 08:01

23Currently module scopes automatically check for functions __get__, __put__, etc and do the *JSAdapter* *JSAdapter|http://blogs.sun.com/sundararajan/entry/self_javascript_and_jsadapter* thing if they find them. I think this is confusing, as people start expecting the same behaviour in other places, it makes public/private module parts harder to implement, and it can really easily be done by just adding a JSAdapter to a module. /hannes

Version 12 by hannes on 24. May 2008, 08:00

20currently some helma 1.x modules were ported. but not all are tested and documented with helma-ng. hannes came up with the question, whether we should rename / rearange them (helma/core/...) and which modules should be included by default. *matthias**matthias* +1 from me! /hannes
21
22==== Remove JSAdapter magic from module scopes ====
23Currently module scopes automatically check for functions __get__, __put__, etc and do the *JSAdapter* thing if they find them. I think this is confusing, as people start expecting the same behaviour in other places, it makes public/private module parts harder to implement, and it can really easily be done by just adding a JSAdapter to a module. /hannes
24
25==== Add explicit web dispatching ====
26Currently helma.simpleweb uses implicit web path resolution via JavaScript properties. Well, already people are starting to ask how to trick their non-JS model domain to make this work with the URLs they want. I think we should just go with some regular expression -> method URL dispatching/registry scheme like virtually every other web framework these days. /hannes

Version 11 by matthias on 23. May 2008, 14:59

11
12==== Testing Framework ====
13derived from jala lib? hannes took some first steps in this direction. *matthias*
14
15==== Documentation Library ====
16i'm currently using jsdoc toolkit. http://code.google.com/p/jsdoc-toolkit/
17version 2.0 had been just released. *matthias*
18
19==== Fix and document the existing modules ====
20currently some helma 1.x modules were ported. but not all are tested and documented with helma-ng. hannes came up with the question, whether we should rename / rearange them (helma/core/...) and which modules should be included by default. *matthias*
21
22
23
24
25
26

Version 10 by Walter on 21. May 2008, 22:58

10Flexible filtering and sorting of collections. Extended prototypes mapped to different tables. Some mechanism to check if the underlying database has changed (directly or through another app) and to update affected collections. // *walter*walter

Version 9 by Walter on 21. May 2008, 22:57

8
9==== More flexible ORM ====
10Flexible filtering and sorting of collections. Extended prototypes mapped to different tables. Some mechanism to check if the underlying database has changed (directly or through another app) and to update affected collections. // *walter*

Version 8 by matthias on 02. May 2008, 12:11

6==== Integration of JSLint database.js module ====

Version 7 by matthias on 02. May 2008, 12:09

5
6==== Integration of JSLint ====
7Add a database.js module. Just moving the existing one doesn't work, because it depends on helma 1.x // *matthias*

Version 6 by hannes on 25. April 2008, 11:07

1Here you can put all your whishes for Helma NG!*Helma NG*!

Version 5 by anton on 22. April 2008, 13:11

4Include *JSLint|http://www.jslint.com/* in Helma NG and disable it as default. The developers who want to have really good code can switch on and configure the options of JSLint in app.properties and get the JSLint error messages in the event-log. // *anton*anton*

Version 4 by anton on 22. April 2008, 13:11

4Include *JSLint|http://www.jslint.com/* in Helma NG and disable it as default. The developers who want to have really good code can switch on and configure the options of JSLint in app.properties and get the JSLint error messages in the event-log. // *anton

Version 3 by anton on 22. April 2008, 12:46

1Here you can put all your whishes for Helma NG!
2

Version 2 by anton on 22. April 2008, 12:44

1==== Integration of JSLint ====
2Include *JSLint|http://www.jslint.com/* in Helma NG and disable it as default. The developers who want to have really good code can switch on and configure the options of JSLint in app.properties and get the JSLint error messages in the event-log.
3Include *JSLint|http://www.jslint.com/* in Helma NG and disable it as default. The developers who want to have really good code can switch on JSLint in app.properties and get the JSLint error messages in the event-log.

Version 1 by anton on 22. April 2008, 12:42

1=== Integration of JSLint ===
3Include *JSLint|http://www.jslint.com/* in Helma NG and disable it as default. The developers who want to have really good code can switch on JSLint in app.properties and get the JSLint error messages in the event-log.