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:28:54 GMT
Jonathan Stimmel wrote:
> 
> On Wed, Jun 21, 2000 at 03:18:46PM -0400, Andy Lewis wrote:
> 
> > The concept of XSP independent taglibs is one I like.
> 
> Ok, here are mu musings on taglibs. Bear in mind that I have not
> played around with XSP-based taglibs much, so I may have some
> misconceptions...

...
 
> In my mind, there are two basic applications for cocoon. In one case,
> cocoon needs to format a page based on a single content source. For
> instance, you might have a news directory filled with xml documents,
> and you want cocoon to display them with a few navigation links. In the
> other (the case I am pursuing in depth), you have a variety of content
> sources which must be integrated into a page.

why? is there a place where Cocoon limits you action for content
generation?
 
> Since XSP was designed as a generator (not 100% accurate, but close
> enough), it works well for the single-source case. I'm not convinced
> it will scale well to handle a dozen (or more) separate content sources.

Of course, it would be easier to write pages that come from a single
location... but I can't see why it should not scale well if more
resources are used.
 
> My biggest argument against XSP-based taglibs (and this may be
> a misconception on my part) is that they can only be used within an
> XSP page. I do want to give the presentation designers the ability
> to choose which content sources are used in a given page, but I do
> *not* want to give our web designers the opportunity to write Java
> code.

Well, don't allow them to do it :-)

Give them a simple layout schema

 <page>
  <banner .../>
  <content .../> 
  <sidebar .../>
  ...
 </page>

and use an XSLT stylesheet to transform the above with XSLT into XSP
with taglibs.

You give the _exact_ power you want to your page fillers since you
control the schema and the stylesheet that adapts it to XSP.

Note how this doesn't slow runtime performance since this happens
_before_ the page is compiled.

> Here's a rough sample of an index.xml file for a news page,
> borrowing a little from XSP/XSL:
> 
>   <!-- XTL == XML Tag Library -->
>   <xtl:page>
>     <page>
>       <xtl:attribute name="title">
>         Today's news in <xtl:requestParam name="category"/>
>       </xtl:attribute>
> 
>       <!-- define the core content of the page -->
>       <core>
> 
>         <!-- pull 10 stories from the current category -->
>         <news:digest>
>           <xtl:param name="category">
>             <xtl:requestParam name="category"/>
>           </xtl:param>
>           <param name="count" value="10"/>
>         </news:digest>
> 
>       </core>
> 
>       <!-- define a couple sidebars -->
>       <sidebar title="Related sites">
> 
>         <!-- pull some links to related sites -->
>         <links:sites>
>           <xtl:param name="category">
>             <xtl:requestParam name="category"/>
>           </xtl:param>
>         </links:sites>
> 
>       </sidebar>
> 
>       <sidebar title="Classifieds">
> 
>         <!-- pull some items from our classifieds database -->
>         <classifieds:list>
>           <xtl:param name="category">
>             <xtl:requestParam name="category"/>
>           </xtl:param>
>           <xtl:param name="count" value="5">
>         </links:sites>
> 
>       </sidebar>
> 
>     </page>
> 
>   </xtl:page>
> 
> If this is implemented as an XSP page, some observant presentation
> designer with a little Java experience can start hacking around
> and adding code. :{

Well, if your employees are that nasty, you can always "adapt" them to
the XSP engine and filter out everything that you don't like... please
not the XSLT filter for this is _sooo___ easy to write

 <xsl:template select="xsp:logic|xsp:expr|...">
  <!-- ignore -->
 </xsl:template>

 <xsl:template select="*|*@|text()">
  <xsl:copy>
   <xsl:apply-templates/>
  </xsl:copy>
 </xsl:template>

(or something like that).
 
> I'm not certain what the ideal taglib specification would be, though
> I've started mocking up some ideas (which I will post at some point).
> My current favorite (as vaguely illustrated above) involves two main
> pieces.
> 
> ** The taglib compiler
> 
> This piece compiles xml pages into tag library classes. The taglib
> would specify:
>   - code to run at load time (==constructor)
>   - parameters which can (and/or must) be set per request
>   - a list of tags to accept
>   - parameters which can (and/or must) be set per tag
>   - output either text or XML nodes
> 
> it would not:
>   - hard-code its namespace, though it might specify a default
>     (sooner or later, someone is going to want to use two
>     different "util:" taglibs on the same page)
>   - accept node trees as input
>   - need to explicitly handle unknown nodes (current taglibs all
>     have a "<xsl:template match="*"> block... quite ugly, IMO)
> 
> (I'm not certain if we should allow advanced programmers to implement
> a taglib directly, but that's a secondary debate...)
> 
> ** The taglib filter/manager
> 
> This piece manages the use of taglibs on a page. It is responsible
> for:
>   - identifying which taglibs are needed on a page (by predeclaring
>     them in the page - my preference - or in the sitemap).
>   - triggering the compilation of taglibs as necessary
>   - mapping namespaces to taglibs
>   - collecting parameters for a tag (rather than forcing
>     the taglib to keep a stack of SAX events)
>   - managing interaction between taglibs (e.g. a tag which
>     generates a string or text node could be used to set the
>     parameter for another tag)
> 
> Things I'm still puzzling over:
> 
>   - Should the taglibs be processed in a certain order, or should
>     they be called as they are encountered? Processing them in the
>     order they're encountered provides for a (perceived) faster page
>     load, since you've (almost) guaranteed the the data at the top
>     of the page will be generated first. Processing them in a
>     predetermined order makes it possible to cut out the taglib
>     manager, but is more error prone if one taglib must feed output
>     to another.
> 
>   - Do we really need a manager? Without it, you force the taglibs
>     to do more work (they must read their parameters directly from
>     SAX events) and make it more difficult for them to interact
>     (since there's nothing to mediate that interaction). With a
>     manager, however, you can avoid calling taglibs which aren't
>     actually used, whereas a pipeline of taglibs would force each
>     taglib to be hit.

What's wrong with XSLT extentions?

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