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