Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Isn't it too restrictive compared to the variety of what modules do?
Don't think so (returning an Object does not to restrict things that much ;) ), but I haven't thought in detail about all modules, any examples where it wouldn't work?
E.g. those modules that do some xpath extraction on XML data. But maybe that isn't a problem if we consider my JS-as-the-only-EL proposal as we could write 'xpath(om.xmlmodule, "/path/to/element[1]")'.
IMHO, there is no point in such input modules anymore. All you need is
* JS and EL firendly object model with "object factories" ("modules" is banned word)
Not sure object _factories_ is the right word either, as they don't create the object, but give access to them (creation is a particular case of giving access). Something like "object accessor" would be better.
* Support of the EL in the sitemap
Once these two points are here, all existing input modules can be (deprecated and) removed. And all that they did can be then done in the sitemap with EL:
{/request/attributes/user}
WDYT?
Kewl. This will bring to Cocoon both an improved consistency and an improved expressiveness because of the genearlized EL.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
