If you strictly
enforce that your XSP pages don't contain Java code, and
only use custom
tags (Logicsheets) then you don't necessarily have a
problem.
Your efforts here
should focus on creating a useful set of Logicsheets, but
ones that have a
declarative approach, rather than ending up with a series
of procedural
statements.
The alternative
approach is to rely more heavily on your pipeline components
(Actions and
Transformers). You're unlikely to use XSP pages here, but may
have them in
limited form, e.g. to parameterise your XML generation to add
information from
the request/session/etc. Often here the XML you're feeding
into the pipeline
provides cues to the downstream components. See the
SQLTransformer for
example.
I think the best
advice I would give at the moment is to choose ONE of these
approaches rather
than a mix-and-match situation. If you do then your application
is partly
specified in the sitemap (pipeline structures) and partly in XSP pages
(XML +
Logicsheets) which isn't nice for maintainance: everything isn't in a single
place.
The interesting
aspect to all this is that if you look a bit closer they're actually
equivalent:
When an XSP page
is transformed into Java code, Cocoon determines the
correct logic
sheet transform to apply for each of your tags. This is repeated
until all thats
left are XSP elements. At that point the final transformation is
carried out to
generate Java code. This is then compiled and execute. So
you have a process
which: determines the code required for this task,
then executes
it.
When a Pipeline is
triggered in the pipeline, Cocoon builds up the Pipeline
components
(perhaps affected by various Actions along the way). Once the
pipeline is built
its then executed.
So a useful
question to ask is: which approach give you the most
flexibility?
The advantages of
putting things in the sitemap is that you're beginning to
approach the "Holy
Grail" of computing: component based development. Throw
together a few
pipeline components and you've got an application.
Fantastic.
But, personally
(and this is probably Cocoon heresy!), I think that once you start introducing
fairly specific
Actions and Transformers -- i.e. ones that have limited reuse, or may
be used only in
one
pipeline -- you're possibly going down the wrong path: there's little
value in having
these as components other than Java code, particularly because
the sitemap gets
so complicated that its difficult to see whats going on.
So far I've tended
to use the sitemap for only doing the association between
requests/processing/response rather than defining the processing
steps.
I'd be interested
in what others think.
L.
-----Original Message-----
From: Gernot
Koller [mailto:[EMAIL PROTECTED]]
Sent: 12 September 2002
13:49
To: [EMAIL PROTECTED]
Subject: Is it a good
idea to avoid the use of xsp ?
Hi!
First, thanks for your very quick replies to my last question!
After quite some time discussing and evaluating we made a decision in favor
of cocoon as presentation framework. One major argument for cocoon and against
struts was that in jsp a strict seperation of logic (Java code) and
presentation is not always encouraged. There was also fear that the same
issues might apply to xsp and therefore the decision was made to use cocoon
but to avoid the use of xsp.
I'm very new to cocoon and by now only have a very vague idea about xsp and
issues that might arise using xsp. So what do you think ? Is it a bad idea to
use cocoon but not use xsp ? Is it generally possible to compare jsp and xsp
in that way? Or are these fears inappropiate?
thanks,
Gernot
--
DI Gernot
Koller
mailto:[EMAIL PROTECTED]
phone:+43-676-340 55 52
Do you Yahoo!?
Yahoo! News -
Today's headlines
