cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Stimmel <jon-li...@stimmel.net>
Subject Re: Thoughts on a data-driven web site
Date Wed, 21 Jun 2000 21:52:45 GMT
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.

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.

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.

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


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.

Mime
View raw message