cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject Re: [Cocoon2] XSP 2.0 changes list
Date Mon, 22 May 2000 17:14:52 GMT
Matt Sergeant wrote:
> > 2) Deprecation of <xsp:content>
> >
> > Implementations show that xsp:content is not useful to XSP semantics.
> > Since very element that doesn't belong to the XSP controlled namespaces,
> > will be automatically interpreted as content.
> Having spent exactly 1 day with XSP (including implementation), I'm in way
> over my head here, but from the example:
> . . .
> <p>
>   Good
>   <xsp:logic>
>     String timeOfDay = (new SimpleDateFormat("aa")).format(new
> Date());
>     if (timeOfDay.equals("AM")) {
>       <xsp:content>Morning</xsp:content>
>     } else {
>       <xsp:content>Afternoon</xsp:content>
>     }
>   </xsp:logic>!
> </p>
> . . .
> How would Morning and Afternoon be separated from code above?

Agreed. The example above says it all

> > 3) Optional use of <xsp:page> for pure-taglib usage.
> >
> > This would allow a page like
> >
> >  <whatever>
> >    Today is <util:date/>
> >  </whatever>
> >
> > to be processable by the XSP engine without requiring to wrap everything
> > by <xsp:page>. This will also remove the problem with having to define
> > one and only one content element after <xsp:page>. This is mostly useful
> > for taglib usage.
> I think my implementation allows this already, but I'd have to check. If
> not it's a fairly trivial change.

Cool, Matt. The Java version of XSP doesn't support this yet but it will
pretty soon. The idea here is to relieve XSP authors who (rightfully)
rely strictly on logicsheets from the added verbosity of the <xsp:page>
"meta-root" element.

Note, however, that <xsp:page> will be required for those cases where
class-level logic is required (those not religiously adhering to the
logicsheet cause).

Since <xsp:logicsheet> is a top-level element, its use requires an
enclosing <xsp:page>. To avoid this in the ideal logicsheet-only case,
the old, pi-based logicsheet declaration mechanism will continue to
be honored.

> > 4) Namespace-driven taglib evaluation
> >
> > You should not need to use <xsp:logicsheet> (as currently implemented in
> > Cocoon 1.x) to turn on taglib processing, but it should be automatic,
> > given the XSP engine with configurations that associate the specific
> > logicsheet to the registered namespace.
> Interesting... I had no idea Cocoon's XSP _didn't_ do this, and that's how
> I wrote the Perl implementation. Each sub-taglib is a subclass of the XSP
> class (Apache::AxKit::Language::XSP), and simply calls
> __PACKAGE__->register_taglib(<namespace>). Obviously register_taglib is
> just implemented in the base class and figures everything out for you,
> setting up a hash of package->class mappings. When there's an entry for a
> namespace it uses that class, when there isn't, it calls a default
> function. (all this is done using XML::Parser's SAX-like methods).
> I assumed this was how the SQL taglib was implemented... :-)

This has been in place ever since XSP was first implemented. In fact,
it was initially the _only_ way to declare logicsheets, certainly too
restrictive. Later on, this was augmented by means of the
<?xml-logicsheet?> pi directive.

In Cocoon2, namespace-driven logicsheets continue to be first class
citizens, but a new, top-level <xsp:logicsheet> directive has been
added for logicsheets not "tied" to a particular namespace

View raw message