Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
<snip/>
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]")'.
Not as readable as 'xmlmodule:/path/to/element[1]' but well, it makes it possible to delegate all expression handling to the surrounding context rather than leaving the possibility for each module to invent its own. This apparent constraint actually leads to an enforced consistency
Yes, enforced consistency is an important point.
at the price of a reduced readability...
Doesn't have to be that way. In your 'xmlmodule:/path/to/element[1]' example, the "module" is only responsible for returning an XML object (a DOM e.g.), i.e. the 'xmodule' part of the string, then it is the task of the surrounding context to decide what it want to do with the object. For sitemap usage that would be to use the second part of the string '/path/to/element[1]' as expression through the default sitemap EL, which could be JS or JXPath depending on taste, community decision, sitemap version etc. I would prefer to use the pluggable expressions from template for this.
In the flow context we would have something like cocoon.xmodule instead and we would use relevant Rhino mechanisms for accessing the DOM (or maybe the XMLBean), and this could be done through E4X or some JXPath library.
<snip/>
The important thing for the "modules" is to provide script friendly access of environment data in a simple way. I assumed that the easiest way would be to support "POJO" interfaces with get and set methods and Maps so that it would be easy to use for the reflection parts of ELs and scripting languages, but I don't know that much about it. If an AttributeHolder is a better anwer to those requirements we should take that route instead.
Well, AttributeHolder allows each Module to define his own syntax for accessing properties, which may not be what I want.
The same holds for Java Maps, and I doubt that people have been so creative so that they send XPaths as name ;) It is more that we IMO get better SoC if the context is responsible for accessing the content of a module.
And if we (again) consider JS-as-the-only-EL, this can be replaced by Rhino's Scriptable interface.
As I wrote in another mail we can use Scriptable for the scriptable OM, whithout the "JS-as-the-only-EL" strategy as we allready, AFAIU, have mechanisms for accessing Scriptables from Jexl and JXPath that are used in JXTG. Again I think it is an intresting idea to focus on JS as EL, but I still want to hide the use of JS as EL behind an interface to simplify migration and back compability and also to enforece better SoC in the core.
/Daniel
