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 10:49:45 GMT
Jonathan Stimmel wrote:
> On Thu, Jun 22, 2000 at 09:16:34PM +0200, Stefano Mazzocchi wrote:
> > I mean: does XSP limit your ability to incorporate different content
> > sources into your page?
> No, and I didn't mean to imply that it couldn't. I'm just
> investigating other paradigms.
> > >  - adding a new taglib forces recompilation of any XSP pages which
> > >    use the new tag
> >
> > c'mon, where's the problem for this?
> I'll concede that it's probably a minor point (assuming a decent JDK,
> of course), but it makes recompilation due to a single changed (or
> added) taglib:
>   O(pages using taglib * number of taglibs/page)
> instead of:
>   O(1)

Ok, got it. Still, I don't think anybody cares since it will be possible
to write a "signal all my XSP pages to recompile" crawler and you can
"recompile" your site before reuploading.

It's like saying that XSLT sucks to generate HTML because if you change
one line in your stylesheet you have to regenerate the whole site. I
don't buy that.

> > >  - it allows independent coding efforts to interact with unintentional
> > >    effects (I noticed that the util taglib creates a new code block
> > >    when it needs a variable; what would happen if this was omitted?)
> >
> > ???
> I noticed the following in util.xsl:
>     <xsp:logic> {
>       String __name = ...
>       ...
>     } </xsp:logic>
> and in sql.xsl:
>         <xsp:logic>
>                 {
>                 Integer max_rows = ...
>                 String max_rows_string = ...
>                 ...
>         }
>         </xsp:logic>
> I assumed (perhaps incorrectly) that the "{}" were there to prevent
> variable conflicts with other taglibs. Upon further investigation, I
> did confirm that code chunks from XSP-based taglibs (in Cocoon1) are
> merged to form a single XSP producer/generator, which means you're
> relying on taglib writers to "play nicely".

Of course. Taglibs are not something that you should mess up with, at
least at this very basic level. The SiLLy language would simplify the
creation of a taglib (I hope!), but still only programmers should touch
a taglib... if you content writers messup with a taglib, you DO have
organization problems, but this is nothing we possibly fix from this
side of the fence.
> A related point: how can a taglib maintain state across all pages
> which use it? For instance, could you write a counter tag that would
> track how many times it was hit across all pages that reference it?
> I suppose you could store a field in a database somewhere, but a
> static variable in a class would be much cleaner. (Of course, I
> don't know why you'd want this particular function... =)
> > >  - last I knew, XSP was still built around DOM (haven't checked
> > >    the recent update)
> >
> > XSP are compiled to SAX generators in Cocoon2.
> I had been given the impression that XSP still used DOM internally,
> which it then converted to SAX. I was apparently misinformed...
> > > It's easy to write, but also easy to remove.
> >
> > remove? absolutely not. This is why Cocoon2 removed PIs and created a
> > sitemap. If you want to lock out your XSP page writers, just don't give
> > them access to the sitemap and you're done.
> I didn't mean to say that presentation designers could necessarily
> remove it, but that the person who does have access to that chunk
> could easily be pressured to remove it.

Hey man, a person under pressure might even be tempted to install IIS +
ASP because there is a DCOM component that does exactly what you need.
Later on you find out it's a whole pain in the ass to maintain and those
DCOM components are expensive and their support/performance suck big

Tell me: who should be blamed for that?

> > > Besides, it lacks elegance =)
> >
> > It does? I think correct use of pipelines is nothing but inelegant...
> > but this is just my personal opinion of course.
> I realised that statement was ambiguous as soon as I sent it. I
> meant that using XSL to remove <xsp> tags was (mildly) inelegant.

Oh, sure, I agree. It's mildly inelegant because the people that happen
to work with you are mildly unorganized. (excessive pressure is not the
cause of disorganization, it's mostly the effect)

> I've never disliked the sitemap concept.

Ok, cool.

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