Hi
EB>> Given that MyFaces already complies, can you endorse the
EB>> higher level statement?
Yes, from spec perspective it is safe to include the statement.
(with some warnings)
But make it work properly is the hard part. The most difficult case we
found was a dynamic component tree generated through "binding"
attribute.
Please note components created and refreshed by a facelet tag
handler should not be manipulated by the user. The typical case is
try to move a branch into a custom component as a container.
Facelets algorithm expect a component tree that can be
refreshed, so violate this rule will cause DuplicateIdException. That
cannot be avoided.
regards,
Leonardo Uribe
2015-09-08 15:03 GMT-05:00 Edward Burns <edward.burns_at_oracle.com>:
> >>>>> 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
>