DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15841>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15841 xsp:attribute handled incorrectly ------- Additional Comments From [EMAIL PROTECTED] 2003-01-07 16:47 ------- I've tracked down the problem in xsp.xsl. The current mechanism for collecting xsp:attribute values is clumsy and more urgent than it needs to be, thanks to the fact that it's calling SAX directly. Here's what's wrong: --- <xsl:apply-templates select="xsp:attribute | xsp:logic[xsp:attribute]"/> this.contentHandler.startElement( <xsl:copy-of select="$uri"/>, <xsl:copy-of select="$name"/>, <xsl:copy-of select="$raw-name"/>, xspAttr ); xspAttr.clear(); <xsl:apply-templates select="node()[not( (namespace-uri(.) = $xsp-uri and local-name(.) = 'attribute') or (namespace-uri(.) = $xsp-uri and local-name(.) = 'logic' and ./xsp:attribute) )]"/> this.contentHandler.endElement( <xsl:copy-of select="$uri"/>, <xsl:copy-of select="$name"/>, <xsl:copy-of select="$raw-name"/>); --- Here's my proposed fix, which I'll hopefully tackle soon, because we need this to work, lest I revert to AxKit: * Stop calling xsp:attribute/xsp:logic templates out of order. * Instead of calling this.contentHandler.startElement(uri, name, raw-name, xspAttr): + this.finishElementConstruction(xspAttr); + xspAttr.clear() + this.startElementConstruction(uri, name, raw-name) * New methods in XSPGenerator (or one of its N ancestors): + startElementConstruction() will store the values until finished + finishElementConstruction() will call this.contentHandler.startElement with the stored values + xspAttr. Any thoughts? Is this handled properly under 2.1? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
