cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Stimmel <jon-li...@stimmel.net>
Subject Re: Thoughts on a data-driven web site
Date Fri, 23 Jun 2000 17:57:29 GMT
On Thu, Jun 22, 2000 at 11:44:12PM -0500, Ricardo Rocha wrote:

> > A related point: how can a taglib maintain state across all pages
> > which use it?
> 
> The correct way to achieve the desired effect is:
> 
> [snip]

You're right, and I did see that solution, but I'm not sure I like
it, since you now have two separate pieces to maintain for a simple
function.


I realised last night that this thread has become quite one-sided,
discussing the merits of using logicsheets to produce generators, so
let's turn it around a bit. Is there something inherently wrong with
filter-based taglibs? (I'm not sure either term - taglib or logicsheet -
is really appropriate here, but I'll use taglib to avoid confusion
with XSP logicsheets).


> For logicsheet authoring, the most important such basic principle is
> probably the following: dynamic tags should be substituted _only_ by
> method calls. One should _never_ inline "raw" code: its dangerous,
> error-prone and reveals lack of in-advance design.
> 
> This is so because dynamic tag embodies either 1) a well-defined
> _operation_ on a well-defined object or 2) a well-defined object or
> system _property_.

This is essentially my argument for filter-based taglibs. Each
library corresponds to a single generated class. The potential
problems from inlining raw java don't exist any more than in a
simple XSP page (without logicsheets).

Given the 1:1 correlation between a taglib and a generated class,
a java programmer who is uncomfortable placing their java code
in an XML document could just write the underlying class directly.
As far as I can tell, this is not an option with current XSP
logicsheets (sure, you can write a filter directly, but then
again you don't need XSP to write a Generator...)


> When you say you view logicsheets as compiled classes you're
> probably refering to program-generation logicsheets.

If you mean that the logicsheet will be directly converted into a
compiled class, then yes.


> In both cases (program generation, dynamic tag substitution),
> logicsheets are just code-generation templates; they're not compilable
> themselves.

Which is my point. I don't see any reason *not* to compile them
directly. Given the choice between several large generators (each
consisting of replicated code from a dozen logicsheets) and a
dozen small (since the code is no longer being replicated) filters,
I'd prefer the latter.


The only drawback I can see to compiling taglibs into filters is
that it might result in a slower pipeline. OTOH, it should be less
memory intensive for a large site (since code is not being replicated
across dozens of generators), and it just feels cleaner to me.

I also realised last week that if the taglibs are processed through a
manager of some sort, then it would be very easy to use JavaBeans as
tag libraries (to create simple text nodes, anyway, don't know whether
you'd want to pull XML from a bean).

Mime
View raw message