Hmm? Well isn't that like saying that sitemaps are
"proprietary"
to Cocoon. XSP, to me, provide a valid and useful function.
They
allow me to develop generators with a *minimal* amount of Java
knowledge (which, sadly, is my situation); as far as possible I
avoid using it (except for simple if/then statements and the odd
calculation) but it makes a very useful wrapper for ESQL which,
if you are working with databases, is a *must have* (IMO)
In the end, all XSP and ESQL are is 'logicsheets' which get converted
to Java (still not sure exactly what you mean by "pure"; is there
some
other kind?). So Cocoon takes care of the coding complexity,
allowing
me to concentrate on the logic. And this, again IMO, is a Very
Good
Thing.
The role of XSL is not changed at all - its still required to do the
final
presentation transformations.
Well, that's my model and its worked for me from the days of Cocoon1.
>>> [EMAIL PROTECTED] 28/01/2003 12:55:11 >>>
> In Cocoon 1, I could see that. In Cocoon 2, I think you would be
> hard-pressed to avoid XSP for longer than a week if you were seriously
> trying to solve a problem by using Cocoon.
Huh? We have a very large Cocoon 2 site that pumps tons of complex data
through Cocoon. We don't have a single XSP, nor do we every plan to have
such: I personally don't like XSP since it uses a (mostly) proprietary
language and I'd much rather stick with standard XSL and standard Java...
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
"The CSIR exercises no editorial control over E-mail messages and/or
attachments thereto/links referred to therein originating in the
organisation and the views in this message/attachments thereto are
therefore not necessarily those of the CSIR and/or its employees.
The sender of this e-mail is, moreover, in terms of the CSIR's Conditions
of Service, subject to compliance with the CSIR's internal E-mail and
Internet Policy."
