You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/04/11 22:21:19 UTC
[c2] bugs in xsp engine
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.
* 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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2][patch] (was : bugs in xsp engine)
Posted by Davanum Srinivas <di...@yahoo.com>.
Sylvain,
Thanks a ton for taking the time to send us a patch. Have Checked it in. Please take a look.
Thanks,
dims
--- Sylvain Wallez <sy...@anyware-tech.com> wrote:
>
>
> 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> Index: xsp.xsl
> ===================================================================
> RCS file:
>
/home/cvspublic/xml-cocoon/src/org/apache/cocoon/components/language/markup/xsp/java/Attic/xsp.xsl,v
> retrieving revision 1.1.2.23
> diff -u -r1.1.2.23 xsp.xsl
> --- xsp.xsl 2001/03/21 18:51:15 1.1.2.23
> +++ xsp.xsl 2001/04/12 13:21:46
> @@ -101,19 +101,24 @@
>
> <!-- Start top-level namespace prefix mapping -->
> <xsl:for-each select="namespace::*[not(local-name(.) = 'xsp')]">
> + <!-- Xerces with Saxon generates a "xmlns" namespace -->
> + <xsl:if test="local-name(.) != 'xmlns'">
> this.contentHandler.startPrefixMapping(
> "<xsl:value-of select="local-name(.)"/>",
> "<xsl:value-of select="."/>"
> );
> + </xsl:if>
> </xsl:for-each>
>
> generateContent();
>
> <!-- End top-level namespace prefix mapping -->
> <xsl:for-each select="namespace::*[not(local-name(.) = 'xsp')]">
> + <xsl:if test="local-name(.) != 'xmlns'">
> this.contentHandler.endPrefixMapping(
> "<xsl:value-of select="local-name(.)"/>"
> );
> + </xsl:if>
> </xsl:for-each>
>
> this.contentHandler.endDocument();
> @@ -168,11 +173,20 @@
> </xsl:choose>
> </xsl:variable>
>
> + <!-- Declare namespaces that are not already present on the parent element.
> + Note : we could use "../../namespace::*[...]" to get parent element namespaces
> + but Xalan 2.0.1 retunrs only the first namespace (Saxon is OK).
> + That's why we store the parent element in a variable -->
> + <xsl:variable name="parent-element" select=".."/>
> <xsl:for-each select="namespace::*">
> + <xsl:variable name="ns-prefix" select="local-name(.)"/>
> + <xsl:variable name="ns-uri" select="string(.)"/>
> + <xsl:if test="not($parent-element/namespace::*[local-name(.) = $ns-prefix and string(.) =
> $ns-uri])">
> this.contentHandler.startPrefixMapping(
> "<xsl:value-of select="local-name(.)"/>",
> "<xsl:value-of select="."/>"
> );
> + </xsl:if>
> </xsl:for-each>
>
> <xsl:apply-templates select="xsp:attribute"/>
> @@ -195,9 +209,13 @@
> );
>
> <xsl:for-each select="namespace::*">
> + <xsl:variable name="ns-prefix" select="local-name(.)"/>
> + <xsl:variable name="ns-uri" select="string(.)"/>
> + <xsl:if test="not($parent-element/namespace::*[local-name(.) = $ns-prefix and string(.) =
> $ns-uri])">
> this.contentHandler.endPrefixMapping(
> "<xsl:value-of select="local-name(.)"/>"
> );
> + </xsl:if>
> </xsl:for-each>
> </xsl:template>
>
> @@ -327,11 +345,16 @@
>
>
> <xsl:template match="*[not(starts-with(name(.), 'xsp:'))]">
> + <xsl:variable name="parent-element" select=".."/>
> <xsl:for-each select="namespace::*">
> + <xsl:variable name="ns-prefix" select="local-name(.)"/>
> + <xsl:variable name="ns-uri" select="string(.)"/>
> + <xsl:if test="not($parent-element/namespace::*[local-name(.) = $ns-prefix and string(.) =
> $ns-uri])">
> this.contentHandler.startPrefixMapping(
> "<xsl:value-of select="local-name(.)"/>",
> "<xsl:value-of select="."/>"
> );
> + </xsl:if>
> </xsl:for-each>
>
> <xsl:apply-templates select="@*"/>
> @@ -356,13 +379,19 @@
> );
>
> <xsl:for-each select="namespace::*">
> + <xsl:variable name="ns-prefix" select="local-name(.)"/>
> + <xsl:variable name="ns-uri" select="string(.)"/>
> + <xsl:if test="not($parent-element/namespace::*[local-name(.) = $ns-prefix and string(.) =
> $ns-uri])">
> this.contentHandler.endPrefixMapping(
> "<xsl:value-of select="local-name(.)"/>"
> );
> + </xsl:if>
> </xsl:for-each>
> </xsl:template>
>
> <xsl:template match="@*">
> + <!-- Xerces with Saxon gives namespace declarations also as attributes -->
> + <xsl:if test="not(starts-with(name(.), 'xmlns:'))">
> xspAttr.addAttribute(
> "<xsl:value-of select="namespace-uri(.)"/>",
> "<xsl:value-of select="local-name(.)"/>",
> @@ -370,6 +399,7 @@
> "CDATA",
> "<xsl:value-of select="."/>"
> );
> + </xsl:if>
> </xsl:template>
>
> <xsl:template match="text()">
>
> > ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[c2][patch] (was : bugs in xsp engine)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Re: [c2] bugs in xsp engine
Posted by Berin Loritsch <bl...@apache.org>.
Davanum Srinivas wrote:
>
> Berin,
>
> > When I posted my general algorithm, it was with two assumptions:
> >
> > 1) The Logicsheet application order is set up BEFORE any processing takes place--hense the
> > declarations in "cocoon.xconf" so the XSP engine has that information.
> > 2) Each logicsheet would be applied once and only once.
> >
>
> I have taken care of both conditions in the code that i checked in this morning. :)
Cool! I will check it out now.
>
> Thanks,
> dims
>
> PS: Though am still not handling recursions :(
When I said recursions, it was in the setup context. If you were to set up a
special Set object that inherited from OrderedSet, and overrode the add() method,
all you would have to do is add all dependancies with the same add() method:
class LogicSheetSet extends OrderedSet {
boolean add(Object obj) {
if (obj instanceof LogicSheet) {
LogicSheet ls = (LogicSheet) obj;
boolean retVal = super.add(ls);
LogicSheet[] dependancies = ls.getDependancies();
for (int i = 0; i < dependancies.length; i++) {
super.add(dependancies[i]);
}
return retVal;
}
return false; // never add anything that isn't a LogicSheet
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Davanum Srinivas <di...@yahoo.com>.
Berin,
> When I posted my general algorithm, it was with two assumptions:
>
> 1) The Logicsheet application order is set up BEFORE any processing takes place--hense the
> declarations in "cocoon.xconf" so the XSP engine has that information.
> 2) Each logicsheet would be applied once and only once.
>
I have taken care of both conditions in the code that i checked in this morning. :)
Thanks,
dims
PS: Though am still not handling recursions :(
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Davanum Srinivas a écrit :
> >
> > Donald,
> >
> > As of right now, the code is sub-sub-sub-optimal as it loads each of the specified Logicsheets in
> > the XSP and also recursively loads all Logicsheet's referenced in those first set of LogicSheet's.
> > But now we know it can be done....Any thoughts on optimization? all the code is in addLogicSheet
> > function of AbstractMarkupLanguage.java
When I posted my general algorithm, it was with two assumptions:
1) The Logicsheet application order is set up BEFORE any processing takes place--hense the declarations
in "cocoon.xconf" so the XSP engine has that information.
2) Each logicsheet would be applied once and only once.
The order of application is important in Logicsheets, as well as the number of times it is applied.
I wonder if we can use an Ordered set with a Comparator that checks for dependancies. When the
logicsheets are set up, each Logicsheet will have a list of logicsheets it depends on. That way the
Comparator has something to work with, and the set of Logicsheets applied make sense.
A Comparator has an int return value (-1 is "<", 0 is "==", and 1 is ">"), and two Object parameters.
It would be put together something like this:
class LogicSheetComparator implements Comparator {
private static final int LT = -1;
private static final int GT = 1;
private static final int EQ = 0;
public int compare(Object one, Object two) {
LogicSheet first = null;
LogicSheet second = null;
if (one instanceof LogicSheet) {
first = (LogicSheet) one;
}
if (two instanceof LogicSheet) {
second = (LogicSheet) two;
}
if (first == null || second == null) {
if (second != null) return LT;
if (first != null) return GT;
return EQ;
}
if (first.dependsOn(second)) return GT;
if (second.dependsOn(first)) return LT;
return EQ;
}
}
Apply this Comparator to a OrderedSet, and add the LogicSheets to the set. The Comparator
will take care of the ordering, and everything will only be applied once (we are using a
Set).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Davanum Srinivas <di...@yahoo.com>.
Sylvain,
Give me a day or so. I need to dig a bit more before we jump into implementing
"first-time-applied" param.
Thanks,
dims
--- Sylvain Wallez <sy...@anyware-tech.com> wrote:
>
> Dims, I looked at your changes at XSPMarkupLanguage et al, but didn't
> understand how they solve Donald's problem. What I understand is that
> there's a need for the logicsheet transformer (i.e. the XSL) to know
> that it already has been applied in the generation process in order
> avoid redeclaring some class-level elements (often implemented within a
> <template match="xsp:page">).
>
> If this is the problem, AbstractMarkupLanguage could give the logicsheet
> a boolean parameter indicating if it's applied for the first time or
> not. A logicsheet could then use it as follows :
>
> <xsl:param name="first-time-applied"/>
>
> <xsl:template match="xsp:page">
> <xsp:page>
> <xsl:apply-templates select="@*"/>
> <xsl:if test="$first-time-applied = 'true'>
> <xsp:structure>
> <!-- inner classes, methods and class members declarations -->
> </xsp:structure>
> </xsl:if>
> ...
> </xsp:page>
> </xsl:template>
>
> What do you think of it ?
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Davanum Srinivas a écrit :
>
> Donald,
>
> As of right now, the code is sub-sub-sub-optimal as it loads each of the specified Logicsheets in
> the XSP and also recursively loads all Logicsheet's referenced in those first set of LogicSheet's.
> But now we know it can be done....Any thoughts on optimization? all the code is in addLogicSheet
> function of AbstractMarkupLanguage.java
>
> Thanks,
> dims
>
> --- Donald Ball <ba...@webslingerZ.com> wrote:
> > On Thu, 12 Apr 2001, Davanum Srinivas wrote:
> >
> > > > * 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?
> > >
> > > Just fixed this. Please give it a shot.
> >
> > actually, i just found a bug in this... if i use elements in the esql
> > logicsheet both in my xsp page and in one of the logicsheets it calls, the
> > esql logicsheet is applied twice, causing compilation problems due to
> > duplicate method, variable, and inner class definitions. again, one
> > solution would be to pass a parameter to the logicsheet that indicates if
> > it's the first time it's been applied or not... can't decide if that's
> > optimal or not tho.
> >
> > - donald
> >
> >
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
Dims, I looked at your changes at XSPMarkupLanguage et al, but didn't
understand how they solve Donald's problem. What I understand is that
there's a need for the logicsheet transformer (i.e. the XSL) to know
that it already has been applied in the generation process in order
avoid redeclaring some class-level elements (often implemented within a
<template match="xsp:page">).
If this is the problem, AbstractMarkupLanguage could give the logicsheet
a boolean parameter indicating if it's applied for the first time or
not. A logicsheet could then use it as follows :
<xsl:param name="first-time-applied"/>
<xsl:template match="xsp:page">
<xsp:page>
<xsl:apply-templates select="@*"/>
<xsl:if test="$first-time-applied = 'true'>
<xsp:structure>
<!-- inner classes, methods and class members declarations -->
</xsp:structure>
</xsl:if>
...
</xsp:page>
</xsl:template>
What do you think of it ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Davanum Srinivas <di...@yahoo.com>.
Donald,
As of right now, the code is sub-sub-sub-optimal as it loads each of the specified Logicsheets in
the XSP and also recursively loads all Logicsheet's referenced in those first set of LogicSheet's.
But now we know it can be done....Any thoughts on optimization? all the code is in addLogicSheet
function of AbstractMarkupLanguage.java
Thanks,
dims
--- Donald Ball <ba...@webslingerZ.com> wrote:
> On Thu, 12 Apr 2001, Davanum Srinivas wrote:
>
> > > * 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?
> >
> > Just fixed this. Please give it a shot.
>
> actually, i just found a bug in this... if i use elements in the esql
> logicsheet both in my xsp page and in one of the logicsheets it calls, the
> esql logicsheet is applied twice, causing compilation problems due to
> duplicate method, variable, and inner class definitions. again, one
> solution would be to pass a parameter to the logicsheet that indicates if
> it's the first time it's been applied or not... can't decide if that's
> optimal or not tho.
>
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 12 Apr 2001, Davanum Srinivas wrote:
> > * 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?
>
> Just fixed this. Please give it a shot.
actually, i just found a bug in this... if i use elements in the esql
logicsheet both in my xsp page and in one of the logicsheets it calls, the
esql logicsheet is applied twice, causing compilation problems due to
duplicate method, variable, and inner class definitions. again, one
solution would be to pass a parameter to the logicsheet that indicates if
it's the first time it's been applied or not... can't decide if that's
optimal or not tho.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 12 Apr 2001, Davanum Srinivas wrote:
> > * 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?
>
> Just fixed this. Please give it a shot.
you rock my world, dims. i'd started to poke around in the xsp engine but
got lost in the morass of the, what, 20 different classes and interfaces
that comprise the system. :). this works like a charm. i'll see if i can
come up with an example that would require circular dependencies though.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Davanum Srinivas <di...@yahoo.com>.
Hi Donald,
> * 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?
>
Just fixed this. Please give it a shot.
Thanks,
dims
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Davanum Srinivas <di...@yahoo.com>.
Donald,
- Removed extra class to startPrefixMapping and endPrefixMapping. Please take a look now.
- If you have a sample for the other two problems, please send them to me, i'll look into it.
Thanks,
dims
--- Donald Ball <ba...@webslingerZ.com> wrote:
> 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.
>
> * 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] bugs in xsp engine
Posted by Davanum Srinivas <di...@yahoo.com>.
Donald,
Sebastien Sahuc originally wrote the C2 XSP Engine. Am not sure who else has enough backround in
this component. So as far as i know no one else is looking into these problems/issues.
Thanks,
dims
--- Donald Ball <ba...@webslingerZ.com> wrote:
> 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.
>
> * 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org