You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2008/01/31 01:12:46 UTC
[VOTE] Partial triggers and "::" naming
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 <an...@gmail.com>
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 :-) )
>
>
>
>
>
>
>
>
>
Re: [VOTE] Partial triggers and "::" naming
Posted by Andrew Robinson <an...@gmail.com>.
>
> <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>
>
> with the OLD solution where we started with the parent component we
> wouldn't be able to say E or G on table, correct? Instead we'd have to
> say ::C:E and ::C:G?
Currently implemented:
C:E C:G
The table has to refer to itself
I believe you are right with the OLD behavior. You may know best as you
committed the fix for 757. The OLD way had a larger number of :'s.
>
> Is that correct?
>
> - Jeanne
>
>
> Leonardo Uribe wrote:
> > +1 , use string arrays to use multiple partial triggers makes that the
> > logic of the page be in 2 places, so this solution is good
> >
> >
>
Re: [VOTE] Partial triggers and "::" naming
Posted by Matthias Wessendorf <ma...@apache.org>.
yeah, I am in that boat as well.
clearer.
-Matthias
On Jan 31, 2008 11:37 PM, Jeanne Waldman <je...@oracle.com> wrote:
> I like this solution because it is much clearer to me. I would like to
> know/investigate what someone would have to change in his jspx file
> between this solution and the original solution (before the bug was fixed).
>
> Is it only if the partialTriggers were on a naming container and it is
> looking for its children?
>
> In your example, it is easy for the table to set the partialTrigger of
> his children:
>
> <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>
>
> with the OLD solution where we started with the parent component we
> wouldn't be able to say E or G on table, correct? Instead we'd have to
> say ::C:E and ::C:G?
> Is that correct?
>
> - Jeanne
>
>
>
> Leonardo Uribe wrote:
> > +1 , use string arrays to use multiple partial triggers makes that the
> > logic of the page be in 2 places, so this solution is good
> >
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [VOTE] Partial triggers and "::" naming
Posted by Jeanne Waldman <je...@oracle.com>.
I like this solution because it is much clearer to me. I would like to
know/investigate what someone would have to change in his jspx file
between this solution and the original solution (before the bug was fixed).
Is it only if the partialTriggers were on a naming container and it is
looking for its children?
In your example, it is easy for the table to set the partialTrigger of
his children:
<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>
with the OLD solution where we started with the parent component we
wouldn't be able to say E or G on table, correct? Instead we'd have to
say ::C:E and ::C:G?
Is that correct?
- Jeanne
Leonardo Uribe wrote:
> +1 , use string arrays to use multiple partial triggers makes that the
> logic of the page be in 2 places, so this solution is good
>
>
Re: [VOTE] Partial triggers and "::" naming
Posted by Leonardo Uribe <lu...@gmail.com>.
+1 , use string arrays to use multiple partial triggers makes that the logic
of the page be in 2 places, so this solution is good
Re: [VOTE] Partial triggers and "::" naming
Posted by Bruno Aranda <br...@gmail.com>.
+1 Looks good to me and I have been struggling to understand the existing
thing. Thanks,
Bruno
On 31/01/2008, Martin Marinschek <ma...@gmail.com> wrote:
>
>
>
> > +1 : yes I want this change
>
>
> indeed, I find it a lot more logical like this.
>
> regards,
>
> Martin
>
Re: [VOTE] Partial triggers and "::" naming
Posted by Martin Marinschek <ma...@gmail.com>.
>
> +1 : yes I want this change
indeed, I find it a lot more logical like this.
regards,
Martin
Re: [VOTE] Partial triggers and "::" naming
Posted by Andrew Robinson <an...@gmail.com>.
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 <an...@gmail.com>
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 <an...@gmail.com>
> 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 :-) )
> >
> >
> >
> >
> >
> >
> >
> >
> >
>