cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Normalizing xsp uri namespaces
Date Thu, 15 Feb 2001 16:15:05 GMT
Matt Sergeant wrote:
> 
> On Thu, 15 Feb 2001, Giacomo Pati wrote:
> 
> > Well, to be honest, I have no clue how AxKit logicsheets are written. But as
> > the syntax for XSP is normated why could AxKit not profit from a
> > preprocessing of a "raw" logicsheet? Don't you use XSLT to apply a logicsheet
> > to an XSP page?
> 
> Nope, not at all. Here's our Param logicsheet in its entirity. Note that
> it's basically a SAX handler (its really an XML::Parser handler, but
> they're pretty similar):
> 
> package AxKit::XSP::Param;
> use strict;
> use Apache::AxKit::Language::XSP qw(start_expr append_to_script end_expr);
> 
> use vars qw/@ISA $NS $VERSION/;
> 
> @ISA = ('Apache::AxKit::Language::XSP');
> $NS = 'http://axkit.org/NS/xsp/param/v1';
> 
> $VERSION = 0.60;
> 
> sub parse_start {
>     my ($e, $tag, %attribs) = @_;
>     start_expr($e, $tag);
>     append_to_script($e, '$cgi->param(q|' . $tag . '|)');
>     end_expr($e);
>     return '';
> }
> 
> 1;
> 
> Thats it :-)
> 
> Usage is just <param:foo/> which if this were Cocoon, would generate
> <xsp:expr>$cgi->param(q|foo|)</xsp:expr>, but it doesn't generate raw
XSP,
> the parsing of AxKit XSP is one-pass, always. So this just generates raw
> perl code.
> 
> Of course there's nothing *stopping* you from writing logicsheets in XSLT
> the same as Cocoon, but we just think this way is better from a simplicity
> standpoint, and a parse-time performance standpoint (because we have to
> parse once-per-child with Apache, unlike Servlets). YMMV.

I agree with Matt here: using SiLLy for that is too much since it
imposes more than necessary to XSP engine implementors. AxKit and Cocoon
rely on very similar operational concepts, but they are targetted at two
different schools of thoughts, or mental shapes.

While I believe that AxKit will be killer for ready-to-go few-men-teams
write-and-forget usage (a place were Cocoon indeed sucks!), Cocoon will
take over once the complexity starts to rise and the amount resources
invested (both technical and human) goes along.

The concept of SiLLy might be language-neutral as well as XSP, but its
based on strong architectural concepts that require an investiment from
those logicsheet writers (as well as engine implementors). A price that
might not be efficient to pay for small-to-medium projects.

This is why I believe that if such a CPAN for taglibs is written, the
file to describe the resource (yes, Giacomo, RDF comes immediately to
mind but it's not necessary once we agree on a schema) doesn't need to
be SiLLy or anything that complex... something like

 <taglib>
   <name>SQL</name>
   <author name="Donald Ball" email="balld@apache.org"/>
   <version major="2" minor="1"/>
   <description xmlns:xhtml="...">
    <xhtml:p>this is a short description.</xhtml:p>
   </description>
   <implementations>
    <implementation language="http://java.sun.com/"
package="http://xml.apache.org/cocoon/xsp/taglibs/sql_2.1.war"/>
    <implementation language="http://www.perl.com/"
package="http://www.axkit.org/xsp/taglibs/sql2_1.tar.gz"/>
   </implementations>
 </taglib>

please, consider it just a wide guess to start a discussion, I'm sure
you guys have better schemas in mind than this.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



Mime
View raw message