Explicit support for dynamic component tree manipulation

[eclipse-faces-bot]

In JSF it's possible to manipulate a component tree using Java code after it has been build by the ViewHandler. From the very first JSF version on, there have been explicit APIs to do this manipulation.

E.g.

UIViewRoot root = FacesContext.getCurrentInstance().getViewRoot();
UIOutput output = new UIOutput();
output.setValue("Dynamically added component");
root.getChildren().add(output);

However, the exact moment when this kind of manipulation is legal to do has not been specified. In the past, people have been using various moments in the life-cycle, where success ranged from an exception, the component appearing in the rendered response but not surviving a postback, to everything working as expected. Furthermore, behavior varied between MyFaces and Mojarra.

In JSF 2.0, the PreRenderViewEvent seems like an excellent opportunity for this manipulation, but it has not been specified that this is the right moment and in practice implementations might still not support full manipulation here. See http://java.net/jira/browse/JAVASERVERFACES-1826

Proposal: Explicitly provide support for dynamic component tree manipulation, possibly by proving a special system event for this and mandating conforming implementations to fully allow such manipulations. In case this is not technically feasible, specify what kind of manipulations are guaranteed to work.

[eclipse-faces-bot]

@glassfishrobot Commented
Reported by @arjantijms

[eclipse-faces-bot]

@glassfishrobot Commented
kennardconsulting said:
Hi guys,

Thanks for opening this spec issue!

I'd like to point out that MyFaces, as of 2.0.3, has successfully supported dynamic component tree manipulation in all my SystemEvent Acid Tests (see https://issues.apache.org/jira/browse/MYFACES-2935) and in Metawidget (http://metawidget.org) which exercises dynamic component tree manipulation more than most.

So this spec change may be as simple as 'blessing' the MyFaces behaviour. Certainly this would seem preferrable to introducing a new SystemEvent. My only concerns:

1. The name of PreRenderViewEvent is fine, but the way you have to use it seems odd:

root.subscribeToViewEvent( PreRenderViewEvent.class, this );

I believe Ryan Lubke came up with this approach (see http://kennardconsulting.blogspot.com/2010/10/safely-manipulating-component-tree-with.html). It works, but it seems strange a component has to register against the 'UIViewRoot.subscribeToEvent' as opposed to just calling 'this.subscribeToViewEvent'? Perhaps this could be explained and documented in the spec.

2. Rinner23 has expressed concerns whether PreRenderViewEvent works inside a UIRepeat (see http://java.net/jira/browse/JAVASERVERFACES-1826?focusedCommentId=308718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_308718). I have never tested this use case myself.

Regards,

Richard.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Bulk assign all of Sheetal's spec issues to me.

[eclipse-faces-bot]

@glassfishrobot Commented
@arjantijms said:
rogerk hinted at a possible necessity for this behavior to be spec'd:

I know there was some initial discussion on the EG related to this area - perhaps some of this should be spec'd so implementations have a blueprint to follow and MyFaces/Mojarra will be doing it the same way.

See: http://java.net/jira/browse/JAVASERVERFACES-1826?focusedCommentId=316876&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_316876

[eclipse-faces-bot]

@glassfishrobot Commented
kennardconsulting said:
I have done some further experiments using PreRenderViewEvent within 'repeater' components (such as ui:repeat and h:column).

There appears to be a fundamental problem whereby components that use PreRenderViewEvent cannot also access 'bound attribute values' (such as <h:dataTable var="internal">). Ed believes this is defined at the spec level, so needs to be fixed there too.

See http://java.net/jira/browse/JAVASERVERFACES-2089

Note there is a workaround if the parent component is defined by the developer. But this workaround is not available when using the built-in components (such as h:column).

See https://issues.apache.org/jira/browse/MYFACES-3168

[eclipse-faces-bot]

@glassfishrobot Commented
@manfredriem said:
All the changes included in 1826, 2371, 2372 and 2373 should account for the ability to manipulate the component tree. Note that dynamic component tree manipulation can happen at any time after restoring the view and before state saving.

[eclipse-faces-bot]

@glassfishrobot Commented
kennardconsulting said:
I must point out that "the changes included in 1826, 2371, 2372 and 2373" do not fully "account for the ability to manipulate the component tree". Several show stopper bugs remain, as reported here http://java.net/jira/browse/JAVASERVERFACES-2283

Please address this! I have been waiting 2.5 years

[eclipse-faces-bot]

@glassfishrobot Commented
@arjantijms said:
Please also note the difference between the practical ability of Mojarra to allow dynamic manipulation and the spec actually demanding that compliant implementations should support this.

[eclipse-faces-bot]

@glassfishrobot Commented
@manfredriem said:
OK I guess I need to clarify what I meant with my previous comment about 1826, 2371, 2372 and 2373. As this is a spec issue what I meant with it was the fact we have now identified at what point in the lifecycle it is save to do dynamic component tree manipulation. The following clarification / explanation can be added somewhere in the JavaDoc and/or specification. So any JSF implementation is aware of what is expected with regards to dynamic component tree manipulation.

"Dynamic component tree manipulation can happen at any time during and after restoring the view and before state saving and needs to function properly with respect to rendering and state saving"

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

[eclipse-faces-bot]

@glassfishrobot Commented
@manfredriem said:
Setting priority to Critical

[eclipse-faces-bot]

@glassfishrobot Commented
File: dynamic.diff
Attached By: @manfredriem

[eclipse-faces-bot]

@glassfishrobot Commented
@manfredriem said:
Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1007, Explicit support for dynamic component tree manipulation"
Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Transmitting file data .
Committed revision 15198.

[eclipse-faces-bot]

@glassfishrobot Commented
Marked as fixed on Tuesday, September 15th 2015, 7:01:24 am

[eclipse-faces-bot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-1007

[eclipse-faces-bot]

• Issue Imported From: Explicit support for dynamic component tree manipulation javaee/javaserverfaces-spec#1007
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @manfredriem
• Original Issue Closed By:@glassfishrobot