Hi,
As the issue asked most to explicitly support dynamic tree
manipulation I think the statement is fine for this issue.
I do however agree with Leonardo that the current syntax is not ideal.
It's not really the kind of syntax or API usage one would easily
guess.
For advanced JSF users, it's not so much an issue, but as we also like
to make JSF more approachable (easier) for general users it would not
be bad if we could indeed make things easier here as well.
So for now:
Step 1; Officially acknowledge dynamic tree manipulation - done
Step 2; Make it easier - open
I think Step 2 may best be done in the context of a new issue/new discussion.
Kind regards,
Arjan Tijms
On Wed, Sep 9, 2015 at 3:18 PM, manfred riem <manfred.riem_at_oracle.com> wrote:
> 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>:
>>
>> >>>>> 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
>
>