See the tail end of issue 1383  for the full history.
High level details:
Thanks again for your reply. You say 'in the current implementation', but I
suppose the big question is what is in the spec? The way it works at the moment
means it cannot support my use case. Specifically:
1. Custom components that want to 'safely' manipulate the component tree (ie.
before it gets serialized)
2. Custom components that want to nest instances of themselves during that
I was under the impression PostAddToViewEvent was created for the sake of point
1. It does not seem a stretch to ask it to work for point 2. But if not, is
there some other way?
The spec is silent in this area. That said, as I see it, the problem with
supporting option two is due to the API itself.
The Application object is a consumer of the List<SystemEventListener> returned
by UIViewRoot.getViewListenersFor(Class<? extends SystemEventListener>. I
think it would have been better to return an Iterator here instead of a List so
that we could enforce that modifications to the underlying data structure would
be through the subscription mechanism.
Since the API calls for a List, that means we have to support all of the
modification mechanisms supported by that interface. Assume for a moment that
we switch the List implementation that supports all of the modification methods
and the Iterators that it returns are not fail-fast. So, for the simple case,
we could support iterating over listeners that were either added via the event
subscription methods or if the List was manipulated and the listener was added
to the end of the List. However, things start to fall apart if the listener was
added at a specific index. That could mean the listener is never invoked at all
by the iteration, or another listener could potentially be invoked twice.
One possible solution to this would be to return an unmodifiable collection when
getViewListenersFor() is called so that it's only possible to modify the
underlying collection via subscription, but that goes back to my original point
about the API exposing the List in the first place. Granted, the javadocs are
silent as to whether or not the List to be returned is modifiable or not, but
I'm sure if we changed it to be unmodifiable, we'd get complaints.
As to an alternative, I'll have to think about it a bit more.
I completely agree with your reply. It is a complex issue and I don't have a
I guess my high-level feeling is that Metawidget (http://metawidget.org) is a
really good example of exactly the kind of highly dynamic component that led to
the inception of events such as PostAddToViewEvent in JSF2: it was recognised
JSF needed a 'safe' place to manipulate the component tree. But perhaps what
was NOT recognised was that if that 'safe' place was via an event model, and
there was not a safe place to manipulate the event model itself, then you could
never have dynamic components that generated other dynamic components.
My option 2 in my previous comment was understating the case: it doesn't have
to be a dynamic component that creates an instance of itself. It will be any
dynamic component that in turn tries to create another dynamic component.
I'll think about it some more too...