cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Towards a unified scripted object model (was Re: JS versus Java)
Date Mon, 28 Feb 2005 22:47:54 GMT
Daniel Fagerstrom wrote:

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


Thanks!

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


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.

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

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

Sylvain

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110951018813120&w=2

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message