cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject [c2][patch] (was : bugs in xsp engine)
Date Thu, 12 Apr 2001 14:19:52 GMT


Donald Ball a écrit :
> 
> hey guys. i've been encountering some fun bugs in the c2 xsp engine. i'm
> trying to work them down to their simplest cases, but it's not easy going.
> basically, the namespace-based logicsheet application mechanism doesn't
> work properly:
> 
> * if you fail to declare a logicsheet namespace that's not used in your
> source xsp page, but only in a logicsheet it calls, that logicsheet is not
> applied. i think this is a well known bug, is anyone working on it?
> 
> * xsp pages end up with many unnecessary SAX calls to startPrefixMapping
> and endPrefixMapping. waste of cpu cycles, and it makes debugging painful.
> 

I was just working on this point ! The problem is that the "namespace::"
axis matches every namespace visible from the context element even if
that namespace was declared by a parent element. So all visible
namespaces are declared for every element.

I had to fight with Xalan bugs and strange Xerces/Saxon interaction (see
comments) but finally succeeded in patching xsp.xsl so that namespaces
mappings are generated only if they're declared on the current element.
On C2 samples XSPs, this leads 30% smaller class file and approx 70%
less method calls (the higher the number of logicsheets used, the higher
the reduction). 

Note that this certainly also affects C1 as well. I'll have a look and
submit a patch for C1.

> * logicsheets which you do declare in your source xsp page and use in
> another logicsheet aren't invoked consistently. fer instance, i have a
> logicsheet that contains this snippet:
> 
>           <w:date><xsp:expr>date_format.format(new Date())</xsp:expr></w:date>
>           <xsp:logic>
>             if (<xsp-request:get-parameter name="randomize"/> == null) {
>               <w:body-background-color>#999999</w:body-background-color>
> 
> the generated source code looks something like this:
> 
> this.contentHandler.startElement("http://intranet.webslingerZ.com/xml/site/v1",
>                                        "date", "w:date", xspAttr);
>       xspAttr.clear();
>       XSPObjectHelper.xspExpr(contentHandler,
>                               date_format.format(new Date()));
> this.contentHandler.endElement("http://intranet.webslingerZ.com/xml/site/v1",
>                                      "date", "w:date");
>       this.contentHandler.endPrefixMapping("xsp");
>       ... lots more endPrefixMappings - almost certainly unnecessary ...
>       if (this.contentHandler.startPrefixMapping("xsp",
> "http://apache.org/xsp");
>           this.contentHandler.startPrefixMapping("xspdoc",
> "http://apache.org/cocoon/XSPDoc/v1");
>           this.contentHandler.startPrefixMapping("esql",
> "http://apache.org/cocoon/SQL/v2");
>           this.contentHandler.startPrefixMapping("w",
> "http://intranet.webslingerZ.com/xml/site/v1");
>           this.contentHandler.startPrefixMapping("wzi",
> "http://intranet.webslingerZ.com/xml/xsp/v1");
>           this.contentHandler.startPrefixMapping("xsp-cookie",
> "http://apache.org/xsp/cookie");
>           this.contentHandler.startPrefixMapping("xsp-request",
> "http://apache.org/xsp/request");
>           xspAttr.addAttribute("", "name", "name", "CDATA",
>                                "randomize");
> this.contentHandler.startElement("http://apache.org/xsp/request",
>                                            "get-parameter",
> "xsp-request:get-parameter",
>                                            xspAttr);
>           xspAttr.clear();
> 
> so as you can see, it's trying to create a literal result element
> <xsp-request:get-parameter name="randomize"/>. i strongly suspect, of
> course, that this is due to the request logicsheet being applied before
> mine, and not being applied again afterwards, even though there are
> elements in its namespace in the result tree. anyone have any plans to (or
> ideas for) tackling this?
> 
> - donald
> 

I've looked at XSPMarkupLanguage.java : XSP dependencies are not
expresses by namespace declaration, but either by <xsp:logicsheet
location="..."/> children elements of the root element (and before any
other element) of by <?xml-logicsheet href="..."?> processing
instructions.

Why couldn't we use namespaces ? Well, while solving the overnumerous
namespace declaration problem, I observed that the location of namespace
declaration in the output of an XSL processor cannot be reliably
determined (and thus cannot be used to express stylesheet dependencies)
since XSL processors can output namespace declarations in various ways
(XSLT spec doesn't say anything about this).

Some of the possible behaviours include :
- copy all namespace declarations of the input document in the output
document even if they're not used : in that case you could be infinitely
applying the logicsheets (fun, no?),
- declare the namespaces of the included logicsheets only on elements
belonging to that namespace. In that case, associated logicsheets are
not applied at all and it seems to be what happens in the example above.

So the conclusion is :
- logicsheet declaration with namespaces can only be used for the
toplevel element of the XSP document,
- logicsheet dependencies must be expressed with <xsp:logicsheet> or
<?xml-logicsheet?> and namespaces cannot be used for this purpose.

Could some of our beloved commiters apply the patch on xsp.xsl ?
Thanks.
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
Mime
View raw message