cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Thoughts on a data-driven web site
Date Wed, 21 Jun 2000 23:21:10 GMT
I've been watching over this thread quietly but I have things to say.

Ricardo Rocha wrote:
> 
> Andy Lewis wrote:
> > Is there any intent to implement those two missing details? Or interest in
> > including them if written?
> 
> I presume you're refering to the generic filter handler and accompanying
> logicsheet that would be required for XSP to generate Cocoon filters.

Different issues were raised:

1) Cocoon is XSP-centric
2) XSP is generation-centric
3) We don't have taglib filtering

Ok, here are my personal opinions:

1) Cocoon is XSP-centric: bullshit, the sitemap considers XSP just
another type of generator (much more complex, but still a generator).
XSP is a simpler way to create generators. If there was no XSP you guys
will kick me in the ass all day long saying: hey, dude, writing
generators by hand is a pain in the ass! Still, _nothing_ forces you to
use XSP.

2) XSP is generation-centric: true. This was the main difference between
DCP (Ricardo's Dynamic Content Processor found in Cocoon1) and XSP: DCP
is a filter, XSP is a generator. DCP works on stuff already generated,
XSP can generate from scratch (or from other sources).

3) We don't have filtering taglibs: yes/no. You can always write your
own filters to perform this, but I don't understand _why_ you would do
so. See below.
 
> My personal feeling is yes, we should implement those. I recall Stefano
> mentioning that using XSP for generating filters was overkill or
> something
> along those lines. In principle, I don't see why we shouldn't do that...
> Stefano?

XSP was designed to be a generator, not a filter. Unlike XSLT which was
designed to be a filter and not a generator.

XSLT provides a hack to use it as a generator (mean: work without
anything to style). Interesting hack: a stylesheet that styles itself.

The old tune: XSP is a subset of extended XSLT. True, you all know I
agreed with that. We could remove XSP and use stand-alone XSLT
sytlesheets with extentions as taglibs....

Why this hasn't happened? Because it's a hack, it's _not_ elegant, it's
using the golden hammer, it's flexibility syndrome.

Do I need to say anything else?

I'm sure you can _force_ the XSP syntax to write filters.... but what do
you gain? Filtering a tag _requires_ this tag to be generated, then
interpreted at runtime, then some logic executed, then the tag replaced.

While, if you compile this into an XSP page, you remove the
interpretation overhead.

This is why Donald moved its SQLProcessor over to taglibs: you don't
loose functionality and you gain in runtime performance and taglib
development performance. (a tag-interpreting filter is a _very_ boring
and error prone task, as you might have experienced)

There is _only_ one case where you can't move taglibs over to the
generation side: when you need to know the generated code of the other
taglibs!!!

For example: on a news page, depending on RDF markup inside your
content, you want to add pictures of the people described in the page in
the document side (or using some pop-up DHTML to show it when you move
over with the mouse).

You _can't_ transform this into an XSP taglib... you should use extended
XSLT for this... or write your own filters. (painful, I know, but
forcing XSP not to do its job might be even worse)
 
> Let's take into account, though, that the XSLT filter can do dynamic
> content
> generation by means of extension elements and functions. With this, it
> may
> well be the _only_ filter type.

I totally agree. For symmetry, you can plug your own filter, but I think
XSLT is all you need for all your filtering experience.
 
> Btw, the XSP code generation could be used to generate extension
> handlers as well. This looks very interesting...

This is a totally different issue.

Scott already suggested that XSP might be used as handler creators or
some of our XSP subsystem may be reused there... unfortunately, I can't
see how given the totally different implementation of the two
technologies... but I'm wide open to suggestions, expecially if we end
up integrating Sun's "translet" technology for compiled stylesheets.

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



Mime
View raw message