Uli Mayring wrote:
>
> On Sun, 15 Jul 2001, Jeremy Quinn wrote:
>
> > Being able to make Actions using XSP TagLibs allows existing XSP languages
> > a route into the 'ideal' way of working with Cocoon 2, where they have
> > developed out of the usage patterns in Cocoon 1.
>
> Why not drop Actions altogether and instead put XSP taglibs in that place?
Why not drop XSP altogether and instead put everything in the sitemap?
> It's all just Java, so why should we have two places to do our custom
> logic? From what I hear Actions allow more than XSP (redirects etc.), but
> XSP taglibs have the better interface (XML). So just put XSP in the place,
> where Actions are right now and we'd all be fine?
Personally, I don't like runtime generated and compiled classes. While
they are great for quickly getting a system to run, they are a pain to
debug. Was the problem my markup? Was the problem in the code? It is
vertually impossible for the generated code to spit out error messages
that refer to the original markup. When you are debugging, you may
find out that you have a SQLException in line 981 (of the generated
class file). What about transferring that back to the XSP? It would
be great to find out that there was a SQLException in line 22 of the
XSP page. This is not going to happen anytime soon.
Also, I like separating my code into concern areas if at all possible.
Actions and XSP pages have different responsibilities.
All that being said, there are a number of people who would like to see
compiled Actions. However, noone wants to take the responsibility yet
of creating the Action markup and compilation procedure.
When you add the fact that Actions have no display function (by design),
there is little to gain by incorporating compiled actions. You will
find
that it is easier to create and maintain Java actions than compiled
actions.
S/MIME Cryptographic Signature
