jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: Potential issue with hierarchical variable mapper in Facelets

From: Edward Burns <edward.burns_at_oracle.com>
Date: Thu, 8 Jan 2015 05:26:03 -0800

>>>>> On Thu, 8 Jan 2015 12:38:23 +0100, arjan tijms <arjan.tijms_at_gmail.com> said:

[Clear and concise exposition deleted]

AT> In other words, the setAttribute call would end up influencing the
AT> outer FaceletContext's variable mapper, which I think is not
AT> correct.

Ah, welcome to an instance of the biggest challenge we face in evolving
JSF. While this may not be correct, it is established behavior, and
rather fundamental behavior at that.

[...]

AT> Example of an effect that I think will now happen:

AT> Suppose we have a Facelets tag mytag.xhtml, with a Java based tag
AT> handler for "sometag" that sets a value on the variable mapper.

AT> mytag.xhtml
AT> ...
AT> <x:sometag var="foo" value="bar"/>

AT> On a Facelet:

AT> <test:mytag>

AT> #{foo}

AT> This will print "bar", mytag was able to modify its outer scope

AT> But on the same Facelet when used instead:

AT> <test:mytag dummy="unrelated">

AT> #{foo}

AT> This will now print nothing, the mere presence of the totally
AT> unrelated attribute "dummy' changed the tag's behaviour. I checked
AT> both Mojarra and MyFaces and from a glance at the source they both
AT> seemed to do pretty much the same thing (obviously they both inherited
AT> from the same original Facelets code).

I'm leery of changing this established behavior. I'd like to hear from
component vendors about the impact they think your proposed change would
have on their customers.

Cagatay? Ken Fyten? Andy Schwartz?

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 40 days til DevNexus 2015
| 50 days til JavaLand 2015
| 60 days til CONFESS 2015