>>>>> On Fri, 04 Sep 2015 12:07:01 -0500, manfred riem <manfred.riem_at_oracle.com> said:
MR> While I understand the underpinning desire here I do not want to go
MR> beyond adding the following statement to UIComponent:
MR> Dynamically modifying the component tree can happen at any time,
MR> during and after restoring the view, but not during state saving and
MR> needs to function properly with respect to rendering and state
MR> saving
Please allow me to wordsmith this a little more. First, I think a
better place to put this is in the javadoc for getChildren() since the
word "mutable" in that javadoc is where all the problems start.
Naturally, you could mention in the top level class javadocs that JSF
2.3 introduced some clarifications regarding dynamic components and to
please see the javadoc for getChildren().
Within the javadoc for getChildren(), put the new text after the bullet
list (not in the bullet list of course). Here is my proposed new text.
It is permissible to modify the list returned from this method at any
time during and after PhaseID.RESTORE_VIEW but not during state
saving. The results of manipulating the component tree during state
saving are unspecified. Dynamic component manipulations must function
properly with respect to rendering and all supported state saving
modes.
>>>>> On Sun, 6 Sep 2015 22:19:52 -0500, Leonardo Uribe <leonardo.uribe_at_irian.at> said:
LU> I remember this problem does not point in that direction. Let's take a look
LU> at this code:
LU> public UIAddComponent() {
LU> FacesContext context = FacesContext.getCurrentInstance();
LU> UIViewRoot root = context.getViewRoot();
LU> root.subscribeToViewEvent( PreRenderViewEvent.class, this );
LU> }
LU> The problem here is the constructor is a bad place to do component
LU> manipulation. Why?
Hello Leonardo, thanks for following up on this important topic.
[...detailed code examples showing different viewpoints on the problem
of dynamic component manipulation...]
LU> In JSF 2.0, Richard investigated on a way to do this component
LU> manipulation safely and he just found that PreRenderViewEvent was
LU> a good time to do this dynamic component manipulation. Why?
[...]
LU> Can we do it better? How about this:
[...]
LU> By the previous reasons, I disagree with add the statement proposed,
LU> because it fails to do what it is wanted for this issue, which is define
LU> when and how the developer can do safely dynamic component
LU> manipulation.
That is an admirable and ambitious goal, but given that Arjan originally filed the
issue and already replied on this thread:
>>>>> On Sun, 6 Sep 2015 13:30:05 +0200, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> +1 a very good step in the right direction.
I think we can step back from that with Manfred's higher level approach.
LU> But I have to note that MyFaces complies with the statement, because
LU> we did a big refactor over the algorithm to make the component ids
LU> stable under any circunstance and to support the new dynamic
LU> composite component creation.
Given that MyFaces already complies, can you endorse the higher level
statement?
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 41 Business days til JavaOne 2015
| 56 Business days til DOAG 2015