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
