Hi,
Given the endorsements and unless I hear anything else before 9/11
I will go ahead and add the statement into the Javadoc after the date.
Thanks!
Kind regards,
Manfred Riem
On 9/8/15, 9:04 PM, Leonardo Uribe wrote:
> 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
> <mailto:edward.burns_at_oracle.com>>:
>
> >>>>> On Fri, 04 Sep 2015 12:07:01 -0500, manfred riem
> <manfred.riem_at_oracle.com <mailto: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 <mailto: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 <mailto: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 <mailto:edward.burns_at_oracle.com> |
> office: +1 407 458 0017 <tel:%2B1%20407%20458%200017>
> | 41 Business days til JavaOne 2015
> | 56 Business days til DOAG 2015
>
>