On 1 Feb 2004, at 14:13, Marcin Okraszewski wrote:
Hi,
As I wrote my post with subject "Which XSLT is used for XSP logicsheets???" to the users group I got an idea about XSP transformation to Java.
Why logicsheets are only XSLT ??? Why don't we use the concept of transformers from Cocoon? That would be very useful in some cases!!
This has been discussed a long time ago but it was concieved as flexibility syndrome, therefore rejected.
With the introduction of the compiling classloader, we could even have classes associated with cocoon:// URI and we wouldn't need the concept of XSP anymore since it would all be transparent, even if you would have to drive the XSP pipeline yourself and this would be painful for some given the high number of transforming steps required to go thru the logicsheet evaluation stages.
But we are moving away from dynamically generated java code because we think this is an anti-pattern: appears very appealing at first, but then it turns out to be a painful nightmare for debugging down the road.
We are slowly deprecating server pages in favor of more MVC+ approaches (that is: flows control + business objects + view templates)
In Cocoon 2.2, XSP will probably move to their own block and removed from the core (this means they will still be supported, but not considered core technology and not advocated as "the way").
I see no point in investing in making XSP even more complex than what they already are.
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
