cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting
Date Mon, 28 Feb 2005 18:41:37 GMT
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>> Daniel Fagerstrom wrote:
>>> I based my comment on:
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110942199227672&w=2
>>
>> Ah yes. I was referring to 2.1 and double checked it before sending, 
>> and forgot is had already been removed in 2.2. You therefore had some 
>> valid points. Sorry for the rant, but this whole discussion got me 
>> nervous.

No problem, I get nervous from incompabilities ;)

>> Anyway, this doesn't change my willingness to write a new 
>> implementation which will introduce "cocoon.request.parameters.foo", 
>> "cocoon.request.attributes.bar" etc and will also separate the 
>> "cocoon" and "flow" objects as we already discussed [1].

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.

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.

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.

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.

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.

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).

/Daniel

Mime
View raw message