There were no objections, we will go forward with the changes and include deprecated code to support the old methods (with warnings).
I will create a JIRA issue to monitor this request. -Andrew On Jan 30, 2008 5:12 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > 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 :-) ) > > > > > > > > > > > > > > > > > > >
