You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xsp-dev@xml.apache.org by Robin Green <gr...@hotmail.com> on 2000/12/02 00:19:31 UTC
Re: [C2] xsp-attribute behaviour
Marcus Crafter <cr...@dresdnerbank.de> wrote:
> 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 ?)
Looks like a bug to me, because it breaks with C1 for no good reason, but I
vaguely remember Ricardo talking about this, hence I've cc'd him.
>
> 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 ?).
Not really a problem. The xsp:attribute tag should just be defined to apply
to the current node. If the current node is not an element or not the
intended element, user's SAX code sucks, not our problem. After all SAX _is_
a serial API, it's the developers responsibility to make sure things go out
in the right order.
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com