Just had some offline feedback, and would like to revise my proposed change
as I support the feedback.
New proposal:
For every multiple colon prefix:
- If the current component is a naming container, use the parent
naming container
- Otherwise, find the parent of the current NC
Example use case to illustrate most of the possible permutations:
<f:subview id="A">
<tr:commandButton id="B" />
<tr:table id="C" partialTriggers="::B E G ::H:I:K ::H:N">
<tr:column id="D">
<tr:commandButton id="E" />
<tr:inputText partialTriggers="::B E G ::C ::H:I:K ::H:N" />
</tr:column>
<tr:column id="F">
<tr:commandButton id="G" />
</tr:column>
</tr:table>
<f:subview id="H">
<tr:table id="I" partialTriggers=":::B :::C:E :::C:G K M ::N">
<tr:column id="J">
<tr:commandButton id="K" />
</tr:column>
<tr:column id="L">
<tr:commandButton id="M" />
<tr:inputText partialTriggers=":::B :::C:E :::C:G K M ::N" />
</tr:column>
</tr:table>
<tr:commandButton id="N" />
</f:subview>
</f:subview>
I have been asked to see if we can put this change through, so I am putting
it to a vote. Please vote if you agree on this change (will give the
standard 72 hour window so everyone can have a say):
+1 : yes I want this change
0: I don't care
-0.5: I don't really like it, but I won't stand in the way (and reason)
-0.9: I hate this, but I won't veto it (and reason)
-1: veto and why
-Andrew
On Jan 30, 2008 3:14 PM, Andrew Robinson <[EMAIL PROTECTED]>
wrote:
> Sorry that this email is long, but it is a sensitive issue, so please read
> on.
>
> https://issues.apache.org/jira/browse/TRINIDAD-757
>
> was reported because the behavior of the code did not match the JavaDoc
> description.
>
> Thread: http://tinyurl.com/373smc
>
> At that time, it was decided by others that changing the JavaDoc would be
> easier that changing the code.
>
> The question became -- should "foo" work like UIComponent.findComponent()
> or should it look it the parent component.
>
> I have had feedback from people using Trinidad, that the change is
> breaking current code, so the argument for not breaking ppl. by changing the
> JavaDoc has not panned out.
>
> Take this example:
> <f:subview id="A">
> <tr:group id="B">
> <tr:panelGroupLayout id="C">
> <tr:panelBox id="D">
> <tr:commandButton id="E" />
> <tr:table id="F" partialTriggers="#{pt}">
> <tr:column>
> <tr:commandButton id="G"/>...
>
> Currently, if I want to F to trigger on G, I have to use #{pt} = "F:G". If
> I want F to trigger on E, I have to use #{pt} = "E":
>
> <tr:table id="F" partialTriggers="E">
> <tr:table id="F" partialTriggers="F:G">
>
> Not only is this confusing (well all solutions are a bit confusing
> admittedly), but really bad for performance.
>
> If #{pt} = "F:G", this is the code that happens (NC means NamingContainer.
> "--" refers to the result):
>
> comp = "F".getParent(); -- comp == "D"
> check if comp is NC -- false
>
> (repeat comp.getParent(), test for NC)
> finds "A"
>
> now call "A".findComponent("F:G")
> UIComponent searches in this order to find "F":
> A, B, C, D, E, F
> (note that this code is broken if the JSF 1.2_04-p02 RI
> UIComponentBase.findComponent() but is correct in MyFaces 1.1.5:
> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=690)
>
> Now it searches all the children of F to find G
>
> This code has way too much overhead. I was already at "F", why do I have
> to search for it?
>
>
> What would be cleaner:
> <tr:table id="F" partialTriggers="::E">
> <tr:table id="F" partialTriggers="G">
>
> In the current implementation "::E" and "E" are identical!
>
> In the "cleaner" approach "::E" and "E" are only identical if the current
> component is not an NC.
>
> If you read the UIComponent docs:
> http://tinyurl.com/2dfak5
>
> You will see that for the code
> comp.findComponent("foo")
> if comp is an NC, then it will check if comp is foo, or find the child
> that is foo.
>
> partialTriggers differs from this. That means that if a developer
> understands the JSF method, they will not expect the partialTriggers
> implementation.
>
> What I (and a few of my co-workers) would prefer as the definition of
> partialTriggers:
>
> - If the search expression begins with a single ':', the base will
> be the root UIComponent of the component tree. The leading separator
> character will be stripped off, and the remainder of the search expression
> will be treated as a "relative" search expression as described below.
> - Otherwise, if this UIComponent is a NamingContainer it will serve
> as the basis.
> - Otherwise, search up the parents of this component. If a
> NamingContainer is encountered, it will be the base.
> - Otherwise (if no NamingContainer is encountered) the root
> UIComponent will be the base.
> - If the search expression starts with multiple ':' characters:
> - For each ':' beyond the first, find the parent component
> that is a NamingContainer. Therefore ':::comp' will begin the "relative"
> search from the NamingContainerthat is a ancestor of the NamingContainer
> that comp is a child of.
>
> The search expression (possibly modified in the previous step) is now a
> "relative" search expression that will be used to locate the component (if
> any) that has an id that matches, within the scope of the base component.
> The match is performed as follows:
>
> - If the search expression is a simple identifier, this value is
> compared to the id property, and then recursively through the facets and
> children of the base UIComponent (except that if a descendant
> NamingContainer is found, its own facets and children are not searched).
> - If the search expression includes more than one identifier
> separated by ':', the first identifier is used to locate a NamingContainer
> by the rules in the previous bullet point. Then, the findComponent() method
> of this NamingContainer will be called, passing the remainder of the search
> expression.
>
> This would improve performance, actually give a purpose to "::foo" and be
> in sync with the method of searching for a component based on the JSF
> specification.
>
> Since we know current code is already broken, I do not feel that
> "maintaining backward compatibility" is a valid reason to say no.
>
> Thanks,
> Andrew
>
> PS - Wow, hard to believe you read all that, thanks! (or did you just
> scroll to the end :-) )
>
>
>
>
>
>
>
>
>
