Niclas Hedhman wrote:
On Friday 03 December 2004 22:23, Sylvain Wallez wrote:
Ok, re-read this with a [OT/RT/FS] prefix in the subject. I have not
said I *want* this to go into Cocoon.
Sorry I chose to make the reply on your mail, and not one of the other feature proposals where it perhaps made more sense...
Just wanted to raise a small flag. The creep is scary because one by one, everything makes sense but looking at the accummulated total, I am seeing a picture that scares people away.
I both agree and disagree: Cocoon is a complex beast, we all know that. And despite my long term involvement in its development, there are areas that are totally obscure to me, and some features I don't like. Even some I wrote myself ; we all evolve over time.
However, the current discussion around templates and expressions language is not meant to add yet another feature to Cocoon. It is meant to provide a single solution for needs that are currently implemented in Cocoon, but duplicated in many places with as many variations as there are duplications, as each component (or developper) has reimplemented the feature without really taking care of an overall consistency of the Cocoon system.
Templates and expression languages are system-wide concern, and not only concerns of individual high-level components. So we must define some system-wide architecture to hold implementations of these concerns. Now do we have to sacrifice diversity for this, by imposing e.g. a single expression language? We cannot. Cocoon users form a very diverse community, using the platform in diverse environments, even for a single person. I want a bean-property EL when I use Hibernate, but also a XPath EL when I use XML documents. But I don't want JXTG, XSP, CForms and others to each either impose a particular EL or each provide a different way of choosing the EL. Making a choice should be possible, but in a consistent manner.
So yes, new features will be added. But just like CForms (who's still using XMLForm?), these new features should become mainstream and deprecate their older equivalent.
Now the problem also comes from the combination of a necessary backward compatibility that requires us to keep deprecated features and the lack of docs that indicate what features are the current mainstream ones and those that are only here because of history.
Maybe we should be less shy to deprecate things. But the problem is that deprecation means future deletion, which also scares people as it doesn't give the image of something stable. Maybe some "mainstream-ness" classification would allow people new to Cocoon to more easily find their way into the system, while still giving the necessary code and documentation to people having "legacy" Cocoon applications.
What do you think?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
