Return-Path: <crafterm@dresdnerbank.de>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 10370 invoked from network); 1 Dec 2000 15:47:45 -0000
Received: from purveyor8.dresdnerbank.de (193.194.7.54)
  by locus.apache.org with SMTP; 1 Dec 2000 15:47:45 -0000
Received: from ffzj0yga.dresdner.net (unverified) by PURVEYOR8.Dresdnerbank.de
 (Content Technologies SMTPRS 2.0.15) with ESMTP id
 <B0005066093@PURVEYOR8.Dresdnerbank.de> for <cocoon-dev@xml.apache.org>;
 Fri, 01 Dec 2000 16:47:42 +0100
Received: from lssun001.bank.dresdner.net (lssun001.bank.dresdner.net
 [130.10.64.83])
	by ffzj0yga.dresdner.net (8.8.8+Sun/8.8.8) with ESMTP id QAA21949
	for <cocoon-dev@xml.apache.org>; Fri, 1 Dec 2000 16:47:37 +0100 (MET)
Received: from fztig938.bank.dresdner.net (crafterm@[130.63.96.66])
	by lssun001.bank.dresdner.net (8.9.2/8.9.2) with ESMTP id QAA22118
	for <cocoon-dev@xml.apache.org>; Fri, 1 Dec 2000 16:47:35 +0100 (MET)
Date: Fri, 1 Dec 2000 16:47:36 +0100 (CET)
From: Marcus Crafter <crafterm@dresdnerbank.de>
X-Sender: crafterm@fztig938.bank.dresdner.net
Reply-To: "Marcus Crafter (OSA)" <Marcus.Crafter@osa.de>
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] xsp-attribute behaviour
In-Reply-To: 
 <838E11BB31D0D3119DBF0008C7A47FE7021F88C8@ffz00za6.wwz1me.mail.dresdner.net>
Message-Id: 
 <Pine.LNX.4.21.0012011618470.27851-100000@fztig938.bank.dresdner.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Hi Christian,

	Interesting stuff we're seeing here.

	Just for everyone else's information. Christian and I played around
	with the xsp.xsl file for a while and we noticed some interesting
	behaviour. It's kind of strange, perhaps some one has an idea how to
	solve these issues ?
	
	First issue is that xsp:attribute templates are evaluated after the
	call to 'startElement', in the generic 'handle-all-tags-except-xsp-tags'
	template (xsp.xsl, line 327).
	
	This means child xsp:attribute tags aren't actually associated with
	their parent - they associate to the next tag (is this a bug or
	intended ?)

	xsp:element does things differently though (I would say, more
	correctly), it evaluates xsp:attribute templates first, generates the
	call to 'startElement', and then evaluates all other templates
	(xsp.xsl, line 127) - but this raises a second issue ->
	
	If one uses xsp:logic to create/define a variable, and then uses
	xsp:expr within xsp:attribute then there are no guarantees that the
	variable will actually exist when the xsp:expr is executed.

	Example:

	<xsp:element name="tag">

		<xsp:logic>
			String var = myclass.getVar();
		</xsp:logic>

		<xsp:attribute name="attr1">
			<xsp:expr>var</xsp:expr>
		</xsp:attribute>

	</xsp:element>

	Looks ok, but it isn't. The xsp:element template evaluates first
	xsp:attribute tags, then it creates the call to 'startElement', and
	then it evaluates all other templates (which includes xsp:logic).

	The above example throws an exception because the variable 'var' isn't
	defined - ie. The use of the variable 'var' (xsp:attribute) occurs in
	the generated java code before its definition (xsp:logic).

	The fix to this problem - not sure. We could evaluate xsp:logic
	tags before xsp:attribute to ensure that any developer defined
	variables exist - however that causes all sorts of bother if the user
	has called SAX methods directly in their xsp:logic tags (we don't
	here, but perhaps others have ?).

	Granted, in this example you could do everything in one line between
	xsp:expr, but with more complicated code - one-liners aren't as
	pretty.

	Any thoughts ?

	Cheers,

	Marcus

On Thu, 30 Nov 2000, Schmitt, Christian wrote:

> Hi all,
> please consider the following XML:
> 
> <?xml version="1.0" encoding="iso-8859-1"?>
> <xsp:page language="java"
> 	xmlns:xsp="http://apache.org/xsp">
>   <my-root>
>     <xsp:attribute name="attr">
>       <xsp:expr>new String("something").toString()</xsp:expr>
>     </xsp:attribute>
>     <element>
>       Should have no attribute
>     </element>
>   </my-root>
> </xsp:page>
> 
> I was expecting something like this as output:
> 
> <?xml version="1.0"?>
> <my-root attr="something">
>   <element>
>     Should have no attribute
>   </element>
> </my-root>
> 
> Instead I'm getting the attribute in <element> and <my-root> has no
> attribute.
> Here's a snippet from the generated source code:
>   public void generate() throws SAXException, ProcessingException {
>     try {
>       this.contentHandler.startDocument();
>       AttributesImpl xspAttr = new AttributesImpl();
>       this.contentHandler.startPrefixMapping("xsp",
> "http://apache.org/xsp");
>       this.contentHandler.startElement("", "my-root", "my-root", xspAttr);
>       xspAttr.clear();
>       this.characters("\n    ");
>       xspAttr.addAttribute("", "attr", "attr", "CDATA",
>                            String.valueOf(new
> String("something").toString()) + "");
>       this.characters("\n    ");
>       this.contentHandler.startPrefixMapping("xsp",
> "http://apache.org/xsp");
>       this.contentHandler.startElement("", "element", "element", xspAttr);
>       xspAttr.clear();
>       this.characters("\n      Should have no attribute\n    ");
>       this.contentHandler.endElement("", "element", "element");
>       this.contentHandler.endPrefixMapping("xsp");
>       this.characters("\n  ");
>       this.contentHandler.endElement("", "my-root", "my-root");
>       this.contentHandler.endPrefixMapping("xsp");
>       this.contentHandler.endDocument();
>     } catch (Throwable t) {
>       cocoonLogger.debug("xsp.xsl: handled developer exception: ", t);
>       throw new ProcessingException(t.getMessage());
>     }
>   }
> 
> >From the code I can see that <my-root> is being started with an empty
> xspAttr object. Only then are the attributes added to the xspAttr object and
> then <element> is started (with a now not-empty xspAttr object).
> 
> Is this expected behaviour of the <xsp:attribute> element?
> 
> Thanks for any insight,
> Christian Schmitt

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:           After Hours    : +49 69 49086750