You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/05/22 18:04:40 UTC
[Cocoon2] XSP 2.0 changes list
Hi guys,
XSP is one of the best thing that Cocoon introduced, but experience over
the last months showed there are problems and things that can be tuned.
Here follows a list of things that Ricardo and I would like to
change/improve.
1) Doctype ---------------------
The indicated namespace for XSP 1.0 was
"http://www.apache.org/1999/XSP/Core"
we would like to propose this new URI schema instead
"http://xml.apache.org/cocoon/XSP/2.0"
for the core namespace, then, for taglibs,
"http://xml.apache.org/cocoon/XSP/util/1.0"
where "util" is the taglib name and "1.0" its version.
This allows better visibility of the URI and better control since we
maintain directly the http://xml.apache.org/cocoon/ URI space. Also is
easier to understand and doesn't follow the stupid W3C idea of
year-based URIs cataloging which is just useless and dangerous in the
long run.
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.
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.
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.
So, something like this
<?xml version="1.0"?>
<whatever xmlns:util="http://xml.apache.org/cocoon/XSP/util/1.2">
Today is <util:date/>
</whatever>
will be processed by the XSP engine by using the logicsheet registered
to the namespace in the engine configurations. This improves the current
model because:
- URIs are absolute locations and associate the "meaning" of the taglib,
leaving to the engine configuration the ability to map these namespaces
to the right logicsheet.
- better crossplatform since XSP doesn't rule _how_ the XSP engine
should evaluate those tags or how their content is created.
- better language abstraction since from the point above, every XSP
engine is free to use run-time interpretation or page compilation or
document fragment caching and so forth.
For these below, I'm sure Ricardo will have more to say, so I leave
space for him.
5) Encoding attribute in <xsp:page>
This to allow XSP to generate a declared encoding.
6) Taglib creation kit
This to simplify the creation of taglibs.
7) anything else? (add your comments here)
Let's sort this out soon so that both Ricardo and Matt can upgrade their
engines to allow complete interoperability of pages from one engine to
the other, given that both implement the same taglibs.
Any comment is very appreciated.
Please, make it sooner rather than later :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [Cocoon2] XSP 2.0 changes list
Posted by burtonator <bu...@relativity.yi.org>.
Stefano Mazzocchi wrote:
>
> Hi guys,
>
> XSP is one of the best thing that Cocoon introduced, but experience over
> the last months showed there are problems and things that can be tuned.
> Here follows a list of things that Ricardo and I would like to
> change/improve.
>
> 1) Doctype ---------------------
>
> The indicated namespace for XSP 1.0 was
>
> "http://www.apache.org/1999/XSP/Core"
>
> we would like to propose this new URI schema instead
>
> "http://xml.apache.org/cocoon/XSP/2.0"
+1 here
--
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
Re: [Cocoon2] XSP 2.0 changes list
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi schrieb:
>
> 1) Doctype ---------------------
>
> The indicated namespace for XSP 1.0 was
> "http://www.apache.org/1999/XSP/Core"
> we would like to propose this new URI schema instead
> "http://xml.apache.org/cocoon/XSP/2.0"
> for the core namespace, then, for taglibs,
> "http://xml.apache.org/cocoon/XSP/util/1.0"
> where "util" is the taglib name and "1.0" its version.
>
> This allows better visibility of the URI and better control since we
> maintain directly the http://xml.apache.org/cocoon/ URI space. Also is
> easier to understand and doesn't follow the stupid W3C idea of
> year-based URIs cataloging which is just useless and dangerous in the
> long run.
All +1.
>
> 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.
+1
>
> 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.
+1
>
> 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.
>
> So, something like this
>
> <?xml version="1.0"?>
> <whatever xmlns:util="http://xml.apache.org/cocoon/XSP/util/1.2">
> Today is <util:date/>
> </whatever>
>
> will be processed by the XSP engine by using the logicsheet registered
> to the namespace in the engine configurations. This improves the current
> model because:
>
> - URIs are absolute locations and associate the "meaning" of the taglib,
> leaving to the engine configuration the ability to map these namespaces
> to the right logicsheet.
>
> - better crossplatform since XSP doesn't rule _how_ the XSP engine
> should evaluate those tags or how their content is created.
>
> - better language abstraction since from the point above, every XSP
> engine is free to use run-time interpretation or page compilation or
> document fragment caching and so forth.
Excellent!
>
> 5) Encoding attribute in <xsp:page>
>
> This to allow XSP to generate a declared encoding.
>
> 6) Taglib creation kit
>
> This to simplify the creation of taglibs.
Do you include "suggestions and guide lines on how to desing and evolve
a custom taglib"?
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
XInclude
Posted by roman seidl <rs...@pvl.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Anybody plans for a XInclude Prcessor for Cocoon (or is there already
one)?
mfg
roman
- --
- -------------------------------------------------------------------
Roman Seidl Design & Developement
- -------------------------------------------------------------------
Public Voice Lab Operngasse 24, A-1040 Vienna
Tel.: +43-1-585 22 80/23 Fax: +43-1-585 22 80/99
e-mail: rse@pvl.at web: www.pvl.at
- -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5i
iQA/AwUBOSrVq/g2uKdd4ESJEQLFKgCeNZwuQVz1Jn3GfNj5KvOldpB0kfYAoM3S
ayjyUYv0gM76LlLc09saEYHw
=QqUj
-----END PGP SIGNATURE-----
Re: [Cocoon2] XSP 2.0 changes list
Posted by Giacomo Pati <Gi...@pwr.ch>.
Donald Ball wrote:
>
> On Tue, 23 May 2000, Stefano Mazzocchi wrote:
>
> > 3) you need a way to _debug_ your compiled pages and avoid the "black
> > box" syndrome where the code that goes either comes out fine or
> > generates a (more or less random) compilation problem. (this is, in
> > general, a problem with compiled server pages, but taglibs make this
> > even worse).
>
> taglibs make it even easier, actually, in my experience. when you get a
> stack trace, you get real line numbers in a real library. the XSP part of
> the taglib is just configurating the parameters, in my experience.
>
+1 for Donald. Thats exactly my experience, too.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: [Cocoon2] XSP 2.0 changes list
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
>
> On Tue, 23 May 2000, Stefano Mazzocchi wrote:
>
> > 3) you need a way to _debug_ your compiled pages and avoid the "black
> > box" syndrome where the code that goes either comes out fine or
> > generates a (more or less random) compilation problem. (this is, in
> > general, a problem with compiled server pages, but taglibs make this
> > even worse).
>
> taglibs make it even easier, actually, in my experience. when you get a
> stack trace, you get real line numbers in a real library. the XSP part of
> the taglib is just configurating the parameters, in my experience.
Good point.
Maybe we could design a Taglib interface and let the XSP engine to the
mapping or creating an XSLT skeleton for you... any suggestion?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [Cocoon2] XSP 2.0 changes list
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 23 May 2000, Stefano Mazzocchi wrote:
> 3) you need a way to _debug_ your compiled pages and avoid the "black
> box" syndrome where the code that goes either comes out fine or
> generates a (more or less random) compilation problem. (this is, in
> general, a problem with compiled server pages, but taglibs make this
> even worse).
taglibs make it even easier, actually, in my experience. when you get a
stack trace, you get real line numbers in a real library. the XSP part of
the taglib is just configurating the parameters, in my experience.
- donald
Re: [Cocoon2] XSP 2.0 changes list
Posted by Stefano Mazzocchi <st...@apache.org>.
Paul Russell wrote:
>
> On Mon, May 22, 2000 at 01:58:25PM -0400, Donald Ball wrote:
> > > 6) Taglib creation kit
> > >
> > > This to simplify the creation of taglibs.
> >
> > ha! would love to see it, but i don't see it happening.
>
> Heh. Cynic ;)
>
> Stefano: What exactly did you intend this to comprise?
> I *guess* it would be kindof the XSP 'SDK'...
Currently people are scared by XSP taglibs.
I admit I'm scared too and prefer to write "normal" XSLT logicsheets,
that work more like tag expansion that anything.
Ricardo wrote most of the taglibs and has his hands in everyone that's
been written (not many, in fact).
I, myself, never wrote an XSP taglib.
Why? well, a few reasons:
1) there is no documentation on how to do this.
Taglibs were introduced by Ricardo in what should have become XSP 1.1 or
XSP layer 2 (as we used to call it). Layer 3 should have been the
introduction to XBeans, which would represent the merging of EJB and
XML.
Layer2 got integreated into mainstream and never wanted to write
something because, in all honesty, I didn't believe that much in
taglibs. But I've changed my mind and I do see their main role for
separation of logic and content.
Layer3 is more or less JSP-bullshit and we never did any serious
resoning on that. (Note that even some of the Servlet Experts expressed
their concerns about J2EE marketing crap)
2) you need to know how to create code that merges with the compiled
page without generating errors.
3) you need a way to _debug_ your compiled pages and avoid the "black
box" syndrome where the code that goes either comes out fine or
generates a (more or less random) compilation problem. (this is, in
general, a problem with compiled server pages, but taglibs make this
even worse).
I think Ricardo has more ideas on how to make this simple.
I'll let him talk about it....
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [Cocoon2] XSP 2.0 changes list
Posted by Stefano Mazzocchi <st...@apache.org>.
Jonathan Stimmel wrote:
>
> On Mon, May 22, 2000 at 08:27:34PM +0100, Paul Russell wrote:
>
> > On Mon, May 22, 2000 at 01:58:25PM -0400, Donald Ball wrote:
> > > > 6) Taglib creation kit
> > > >
> > > > This to simplify the creation of taglibs.
> > >
> > > ha! would love to see it, but i don't see it happening.
> >
> > Heh. Cynic ;)
> >
> > Stefano: What exactly did you intend this to comprise?
> > I *guess* it would be kindof the XSP 'SDK'...
>
> I'd like to see this too, but haven't actually started on it yet. I
> envision a taglib processor, which could handle the processing of
> multiple taglibs in a single pass of a document, and which would be
> responsible for the handling of the namespaces (the few taglibs I've
> seen are all hardcoded for a given namespace). Also, from what I've
> seen, taglibs need to be specified in the cocoon configuration file
> (at least, I think they did in cocoon1). This alone has caused me
> to shy away from playing with them (since getting our ISP to make
> configuration changes is rarley a pleasant experience :-/)
These are all good points.
1) avoid configuration changes for taglib usage: this has been solved
with the advent of <xsp:logicsheet> which will allow you to map a
logicsheet to a particular namespace in your own page without requiring
any change in the main configuration.
2) namespace processing: some time ago I proposed the introduction of
the <xsp:namespace> tag to allow content to be automatically transformed
in that namespace without requiring taglibs to provide direct hooks for
such facilities.
I spent a good half an hour today, thinking about this. And I came to
the conclusion that I'm not sure this is a good idea. Let's see why:
there are two possible cases:
1) elements are declared statically
<xsp:namespace prefix="my" uri="http://my.com">
<date>is <xsp:expr>today</xsp:expr></date>
</xsp:namespace>
should generate
<my:date xmlns:my="http://my.com">Today is May 23 2000</my:date>
2) elements are constructed dynamically
<xsp:namespace prefix="my" uri="http://my.com/database/mystuff">
<sql:query>select * from mystuff</sql:query>
</xsp:namespace>
should generate
<my:mystuff xmlns:my="http://my.com/database/mystuff">
<my:row>
<my:column>whatever1</my:column>
</my:row>
<my:row>
<my:column>whatever2</my:column>
</my:row>
</my:mystuff>
In the first case, <xsp:namespace> is nothing different from declaring
the right namespace, since the XSP engine is supposed to let the
namespace declarations be copied over if they don't map to taglibs and
are not expanded.
The useful case is the second.
The problem is: how is this implemented? Possible solutions are:
1) every taglib exposes a sort of API to allow the XSP engine to "push"
the right namespace for the dynamically generated elements/attributes.
2) the compiled page "filters" the SAX events generated by the taglib at
runtime and does an inlined namespace addiction.
Both could work, but while the first is no different from letting each
taglib define its own way to do namespaces (well, right, probably a
standard way it's better anyway, given the importance of namespaces),
the second would reduce performance and go against the paradigm of page
compilation.
So I'm stuck and since Ricardo wants to rewrite the taglib hooks for
simplifying their creation, I think that adding more impositions on
namespaces and such wouldn't help... but I can't really tell until I see
what he has in mind for them.
Ricardo, anything to elaborate on this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [Cocoon2] XSP 2.0 changes list
Posted by Jonathan Stimmel <jo...@stimmel.net>.
On Mon, May 22, 2000 at 08:27:34PM +0100, Paul Russell wrote:
> On Mon, May 22, 2000 at 01:58:25PM -0400, Donald Ball wrote:
> > > 6) Taglib creation kit
> > >
> > > This to simplify the creation of taglibs.
> >
> > ha! would love to see it, but i don't see it happening.
>
> Heh. Cynic ;)
>
> Stefano: What exactly did you intend this to comprise?
> I *guess* it would be kindof the XSP 'SDK'...
I'd like to see this too, but haven't actually started on it yet. I
envision a taglib processor, which could handle the processing of
multiple taglibs in a single pass of a document, and which would be
responsible for the handling of the namespaces (the few taglibs I've
seen are all hardcoded for a given namespace). Also, from what I've
seen, taglibs need to be specified in the cocoon configuration file
(at least, I think they did in cocoon1). This alone has caused me
to shy away from playing with them (since getting our ISP to make
configuration changes is rarley a pleasant experience :-/)
Re: [Cocoon2] XSP 2.0 changes list
Posted by Paul Russell <pa...@luminas.co.uk>.
On Mon, May 22, 2000 at 01:58:25PM -0400, Donald Ball wrote:
> > 6) Taglib creation kit
> >
> > This to simplify the creation of taglibs.
>
> ha! would love to see it, but i don't see it happening.
Heh. Cynic ;)
Stefano: What exactly did you intend this to comprise?
I *guess* it would be kindof the XSP 'SDK'...
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: [Cocoon2] XSP 2.0 changes list
Posted by Ricardo Rocha <ri...@apache.org>.
Donald Ball wrote:
> > 6) Taglib creation kit
> >
> > This to simplify the creation of taglibs.
>
> ha! would love to see it, but i don't see it happening.
Hombre de poca fe!
I do see it happening
Re: [Cocoon2] XSP 2.0 changes list
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 22 May 2000, Stefano Mazzocchi wrote:
> XSP is one of the best thing that Cocoon introduced, but experience over
> the last months showed there are problems and things that can be tuned.
> Here follows a list of things that Ricardo and I would like to
> change/improve.
>
> 1) Doctype ---------------------
>
> The indicated namespace for XSP 1.0 was
>
> "http://www.apache.org/1999/XSP/Core"
>
> we would like to propose this new URI schema instead
>
> "http://xml.apache.org/cocoon/XSP/2.0"
>
> for the core namespace, then, for taglibs,
>
> "http://xml.apache.org/cocoon/XSP/util/1.0"
>
> where "util" is the taglib name and "1.0" its version.
>
> This allows better visibility of the URI and better control since we
> maintain directly the http://xml.apache.org/cocoon/ URI space. Also is
> easier to understand and doesn't follow the stupid W3C idea of
> year-based URIs cataloging which is just useless and dangerous in the
> long run.
Big ol' honking +1.
> 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.
+0
> 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.
+1
> 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.
>
> So, something like this
>
> <?xml version="1.0"?>
> <whatever xmlns:util="http://xml.apache.org/cocoon/XSP/util/1.2">
> Today is <util:date/>
> </whatever>
>
> will be processed by the XSP engine by using the logicsheet registered
> to the namespace in the engine configurations. This improves the current
> model because:
>
> - URIs are absolute locations and associate the "meaning" of the taglib,
> leaving to the engine configuration the ability to map these namespaces
> to the right logicsheet.
>
> - better crossplatform since XSP doesn't rule _how_ the XSP engine
> should evaluate those tags or how their content is created.
>
> - better language abstraction since from the point above, every XSP
> engine is free to use run-time interpretation or page compilation or
> document fragment caching and so forth.
+1
> 5) Encoding attribute in <xsp:page>
>
> This to allow XSP to generate a declared encoding.
+0
> 6) Taglib creation kit
>
> This to simplify the creation of taglibs.
ha! would love to see it, but i don't see it happening.
- donald
Re: [Cocoon2] XSP 2.0 changes list
Posted by Ricardo Rocha <ri...@apache.org>.
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
Re: [Cocoon2] XSP 2.0 changes list
Posted by Matt Sergeant <ma...@sergeant.org>.
First off, to whom it concerns: My email address is matt@sergeant.org -
someone at sergeant.com has kindly (and unbeknownst to me) setup a
forwarding to sergeant.org. But for future please use matt@sergeant.org.
More comments below...
On Mon, 22 May 2000, Stefano Mazzocchi 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?
>
> 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.
>
> 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... :-)
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org