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
