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 }
