Carsten Ziegeler wrote:

Sylvain Wallez wrote:


-1: XSP has been moved to its own block meaning it's no more "core", but hundreds (if not thousands) or people are using it on a daily basis. We can drive people towards new techniques such as flow/jxtemplate, but cannot deprecate what's has been a central part of Cocoon for so many years.

Personal note: your post made many people rush into my office saying "What, what, deprecate XSP? He's crazy!" ;-)


Now they are calling me "crazy" - well... :)

Deprecating doesn't mean removing! by deprecating we show our users
that we think that there are better ways than XSP. And we show that
we are not developing this technique further (of course bug fixes
etc will be applied) That's all. We *can* than remove XSP in another
minor or major release, but we don't need to. So, this is just
a signal.



Before envisionning the deprecation of XSP (which I'm currently against), we must ensure alternative technologies provide a similar level of performance and those of the XSP features that are "clean" from a MVC POV.


These criticisms are of course about JXTemplate:
- performance can be far better if we refactor it to remove the cascade of "if (event instanceof xxx)" used to interpret the template.
- we need cacheable JXTemplates
- we need an equivalent to ESQL which is sooo cool to extract data from a database.


Time for a featured JellyGenerator or TempoGenerator?

Sylvain

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



Reply via email to