Helma NG Wishlist
Here you can put all your whishes for Helma NG!
Contents [hide]
- Integration of JSLint
- database.js module
- More flexible ORM
- Testing Framework
- Documentation Library
- Fix and document the existing modules
- Remove JSAdapter magic from module scopes
- Add explicit web dispatching
- Module repository
- browser based code editor a la AppJet
- Comet/Java NIO support
- Rhino "sandboxing"
- Ability to import AppJet libs as Helma modules
- Dynamic tag libraries
Integration of JSLint
Include JSLint 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
database.js module
Add a database.js module. Just moving the existing one doesn't work, because it depends on helma 1.x // matthias
More flexible ORM
Flexible 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
- filestore (already implemented, in trunk)
- CouchDB (work in progress), see here and here
- JPA - Hibernate version already implemented, needs to be ported<
- Google Gears, see Trimpath Junction for reference
Testing Framework
derived from jala lib? hannes took some first steps in this direction. matthias
already working on it // robert
Documentation Library
i'm currently using jsdoc toolkit. http://code.google.com/p/jsdoc-toolkit/
version 2.0 had been just released. matthias
Fix and document the existing modules
currently 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 +1 from me! /hannes
Remove JSAdapter magic from module scopes
Currently 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
+1 /matthias
Add explicit web dispatching
Currently 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
-> see sandbox/aida/modules/aida/routing.js
Module repository
Provide some sort of automated repository for modules. For instance like the one for Wordpress: http://wordpress.org/extend/plugins/about/ // walter
i would see this later in the roadmap /matthias
browser based code editor a la AppJet
- see an editor we could use here
Comet/Java NIO support
Rhino "sandboxing"
- +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)
Ability to import AppJet libs as Helma modules
- tied in with module repository
- so we can leverage the existing code base
Dynamic tag libraries
- like in Grails
- ... other features from Grails? (e.g. better client side jscript lib integration)