cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Towards a unified scripted object model (was Re: JS versus Java)
Date Tue, 01 Mar 2005 10:22:04 GMT
Damn, you where one minute faster ;) I even considerd starting my title 
with "Towards a".

Sylvain Wallez wrote:

> Daniel Fagerstrom wrote: 


>> Sound like good ideas. IMO we should break out the "cocoon" part of 
>> it to o.a.c.environment and use it both for flow and templating.
> That's exactly my idea. Since we need an object model in a number of 
> scripted locations, let's just try to have one and only one "cocoon" 
> object, identical in all these locations, and add where needed some 
> separate object holders for specific properties and/or features. Just 
> I'd like to introduce this "flow" object, we could have a "template" 
> object if needed. 


>> And if we start improving the environment model for flow and jxtg, we 
>> should make the sitemap, i.e. the input modules, part of the equation 
>> as well.
> Yes. Regarding this, have you read the end of [1] where I suggest to 
> use JS as the only scripting language and eventually introduce 
> specialized languages such as XPath using some additional top-level 
> functions?
> I'd love to have people's opinions on this, as I have the impression 
> this could solve _a lot_ of problems related to the differences 
> between the different expression languages used all over the place in 
> Cocoon.

I read it, but missed that you are suggesting JS as scripting language. 
That certainly opens up some interesting possibilities. Whats my opinion 
about it? Don't know yet ;)

Let's discusses some of the involved concerns.

I think it is a good idea to base the unified scripted object model on 
JS (Rhino). Its allready done in that way in flow/JXTG where the 
introspector for Jexl is extended to be JS aware. I think that it should 
be a future safe bet, Rhino contains most/all of what a scripting 
language should contain. And all decent EL implementations should have 
some possibilities to extend the introspector.

For the use of ELs in core and in other places I prefer to have an 
abstraction layer (like the one I put in the template block) between the 
the use of the EL and the implementation. There might come interesting 
new ELs in the future, this far it doesn't seem like one size fit them 
all for ELs and having it pluggable simplifies migration for users _if_ 
we decide to go for a standard EL. Furthermore, my experience from 
refactoring JXTG is that an abstraction layer helps to keep good SoC and 
leads to cleaner code.

There is a Rhino based EL implementation in JEX (which I based the 
expression stuff in template on), so it should be rather easy to provide 
a pluggable JS EL as well.

For using the same EL everywhere, templates, sitemap etc I don't know. 
It is certainly attractive to have a common language everywhere and 
using JS for both flow and expressions gives coherence. OTH in templates 
I would rather go for a EL with less capabilities for programming than 
more. And I'm not completely happy with making XPath application on DOM 
a second class citisen compared to the more object graph perspective. 
But this area is much a matter of personal taste and software "religion" 
rather than anything "objective", so if the community want coherence I 
would try to tone down my opinions concerning these aspects ;)

>> After all, the "cocoon" part of FOM and the input modules in the 
>> sitemap solves nearly the same problem, giving script/expression 
>> access to the environment. But they do it according to rather 
>> different philosophies.
> Yes, hence my proposal of a single "cocoon" and a single 
> script/expression language. 

Single "cocoon" +1, single script/expression language, maybe.

>> So we need to do a analysis of our needs and the pros and cons of the 
>> both approaches and see if we can find an environment model that is 
>> good enough for sitemap, templates and flow. And preferably something 
>> more elegant and easy to learn than puting FOM and input modules 
>> together with duct tape ;)
>>> big +1
>>> we could even go a step further and provide a 
>>> "legacy_flowscript_FOM" block that contains the old interpreter, and 
>>> the old rhino-continuations library (packages would have to be 
>>> renamed) by Chris. This way we could reach 100-percent-compatibility 
>>> with 2.1 there and everybody could decide when he moves his 
>>> applications over.
>> Agree. The key thing is letting users deciding when to move. 
>> Requiring them to upgrade a number of technologies at once when they 
>> go to 2.2 is to make life to complicated for them. Upgrading will be 
>> much more controlable and atractive if one can change one thing at 
>> the time and keeping most of the application working at all time.
> Exactly. That's why - now that FOM_Cocoon is hopefully clean of back 
> incompatibilities - I'll start working on something new, that will 
> live besides the current implementation. 


>> This is especially important to things like the sitemap, flowscript, 
>> template languages and configurations that might be maintained by 
>> people with less software skills. Deprecation of Java interfaces, 
>> although we should be restrictive with them as well, only affects 
>> people with comparabily high software skills.
> Yes, and scripted languages have a drawback of their scripted nature, 
> as there's no IDE or compiler warning about deprecated features...
>> So as long as we develop things so that makes it easy for users to 
>> update at their rate I'm all for improving the environment handling 
>> (and other things).
> Good. So, quoting Stefano, let's move on. 

Yes :)


View raw message