Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Date: Thu, 22 Jun 2000 16:40:21 -0700
From: Jonathan Stimmel <jon-lists@stimmel.net>
To: cocoon-dev@xml.apache.org
Subject: Re: Thoughts on a data-driven web site
Message-ID: <20000622164021.C21698@stimmel.net>
Mail-Followup-To: cocoon-dev@xml.apache.org
References: 
 <F1E50D2E3D69D211A8F90008C7B1D64C05360AC1@lmoxch11.nsmg.veritas.com>
 <20000621145245.C19380@stimmel.net> <39514FB6.37242660@apache.org>
 <20000622110556.A21698@stimmel.net> <39526612.2EC2A5C9@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <39526612.2EC2A5C9@apache.org>

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)


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

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.


> > 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.
I've never disliked the sitemap concept.