One could think on use a listener attached to PreRenderComponentEvent, but this
event is called before encodeBegin, so it is useless in this case, because we
need to call it before the whole view is rendered.

It does not work too. The reason is the listener is attached to the component
instance, and only the UIViewRoot instance receives the event. If we do the same
as f:event does when PreRenderViewEvent is found (suscribe the listener on
UIViewRoot) we lose the component we are referencing, because it is replaced by
UIViewRoot.

I can solve this one creating a wrapper for ViewHandler that publish a custom
event for all components before render view. but the big question is if jsf 2.0
should support this use case out of the box.

Does not work too because in a postback, PostAddToViewEvent occur in the
following cases:

With Partial State Saving enabled when the view is build but before the state
of the component is restored.

With Partial State Saving disabled when the view is "refreshed", because all
component nodes are detached and attached to the tree.

Now suppose the component has a ValueExpression attached to the property, and
the value changes on Invoke Application Phase. With partial state saving the
tree was already build, so it doesn't catch the logic. With partial state saving
disabled, the event occur twice, the first time when the tree structure is
build, the second time when the view is updated, so again it doesn't work,
because if the resource component (it is transient too) was already added, it
cannot be removed later.

>> Ed Burns
>>
>>Please correct me if I'm wrong, but the problem you state above seems to
>>be just another example of the garden variety "conditional value changes
>>between requests or during a request".
>>

Yes and no. The difference with other examples of the garden is to add a
component resource, we need to do it in the right time, since it requires to
update the component tree adding components before render it, but after we know
which view will be rendered. Please note by a previous fix, all component
resources are transient.

As a side note, if someone wants to do this in a composite component he/she
probable do this:

<c:if test="#

{cc.attrs.....}

">
<h:outputStylesheet ..../>
</c:if>

And it works in myfaces because we have a fix for the c:if problem.

>> Do we need PreAddComponentResourceEvent and
>> PostAddComponentResourceEvent?

In my opinion is only necessary to add only one event. The right place is after
resolve PreRenderViewEvent, because only in that time we know the current
component tree is the view that will be rendered.

It is not possible to use PreRenderComponentEvent because it is called on
encodeBegin and the view header was already rendered.

because the listener is attached to the component when it is created, but the
event is only received by the current UIViewRoot. If we fix the algorithm on
Application class to attach this listener to the current UIViewRoot instance,
the source of the event will be UIViewRoot, and traverse the tree to find the
component is worse. Note other option is publish PreRenderViewEvent for all
child components, but after know the view that will be rendered.

In conclusion, for make this use case possible we need two things:

1. The right time to add the resource to the component tree.
2. The component with its state restored and updated.

Thinking more about it, another option about put this code could be on
vld.buildView method, but note when partial state saving is enabled this method
return immediately (maybe it is possible to change it).