cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Thoughts on a data-driven web site
Date Fri, 23 Jun 2000 21:45:39 GMT
Jonathan Stimmel wrote:
> 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).

No, nothing _inherently_ wrong, but I can't see the need for it unless
you want to postprocess the output of other dynamically generated text
in a dynamic fashion.... something that extended XSLT does perfectly

> > 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...)

I see your point. Well, your approach will always be slower than
compiled generators... but you could achieve better separation, this is
true... hmmmm....
> > 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.

Maybe we could use XSP to compile the taglibs and have a special filter
to invoque those taglibs when the elements are encountered.... well,
c'mon, this is XSLT! Consider that XSLT 1.1 will introduce portable
extentions (hopefully).

> > 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.

Well it might not be that simple: using XSLT to produce code allows you
to "morph" your logicsheet code depending on the nesting of logic
tags... something you can't do with compiled taglibs that are executed
at runtime.

Maybe I'm totally wrong, but I can't see how nested taglibs can work
well if already compiled without the need to impose you very strict
programming practices on how the taglibs are created.

> 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.

good point for memory usage...
> 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).

Ricardo discussed a lot about this... we came up with the idea of
writing an xbean taglib of some sort... but never did anything about
it.... anyway, I don't see how this impact on what we've been talking so
far: you can call a javabean from compiled generators just as well.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message