Hi Thomas,
Your conclusion is spot on.
The problem here is that when the PostAddToViewEvent is dispatched the
tree is not yet in the right format so you'll have to hook in at a later
moment in time (after buildView).
Manfred
On 1/22/15, 3:33 PM, Thomas Andraschko wrote:
> Hi Manfred,
>
> i already answered on the issue list:
>
> As i said, we extract the BV annotations (e.g. @Size) and set the
> maxlength attribute to the InputText component.
> I already thought about doing the logic in our renderes but we can't
> support h:inputText e.g. without wrapping the impl's renderers.
>
> As (i thought) PostAddToView worked fine in every case, it was the
> preferred to implement this feature.
>
> The PostAddToEvent works really fine in every case - it just doesn't
> work with nested CC on a postback.
> It also works with nested CC for the initial request or even one CC
> and postback.
>
> It's just the combo with postback and nested CC.
> I also assumed that something is not ready (e.g. the composite isn't
> completely built or something) but it works fine with one CC - only
> nested CC's doesn't work.
>
>
>
>
> Regards,
> Thomas
>
>
> 2015-01-22 17:25 GMT+01:00 manfred riem <manfred.riem_at_oracle.com
> <mailto:manfred.riem_at_oracle.com>>:
>
> Hi Thomas,
>
> As noted by Ed on the issue:
>
> Ok, Manfred and I have looked at this and discussed it on the
> phone. One concern we have is the timing of when your
> ValueExpressionAnalyzer.getReference() is called. The original,
> package private javax.faces.validator.ValueExpressionAnalyzer is
> only invoked during the handling of BeanValidator.validate(). This
> is called during the processValidations lifecycle phase. At this
> point in the lifecycle all of the composite component retargeting
> and facelet inclusion has already been done.
>
> My question is, when do you actually need to call your
> getReference()? One way to do it is to provide a top-level Java
> component for the composite component and override one of the
> lifecycle methods instead of using PostAddToViewEventListener. For
> example, if you need to do it during page rendering, you could
> override encodeEnd(), call super.encodeEnd() and then invoke your
> listener.
>
> The most important thing to keep in mind is what is the state of
> the tree when your getReference() is called?
>
>
>
> On 1/21/15, 3:47 PM, Thomas Andraschko wrote:
>
> Hi,
>
> as requested on ticket
> https://java.net/jira/browse/JAVASERVERFACES-3490, i'm here to
> discuss it.
>
> As i already said, our ValueExpressionAnalayzer in PrimeFaces,
> which is simliar to yours, works fine in all cases - out of
> one single case:
> A StackOverflow occurs on postback in a
> PostAddToViewEvent-listener with nested CCs.
>
> It works fine in ALL other cases i ever used it.
> PrimeFaces needs to get the original ValueExpression to get
> e.g. the BeanValidation constraints.
>
> I'm sure i must not explain the logic of the
> ValueExpressionAnalyzer as it's almost the same like yours.
>
> I assume, when the PostAddToView-event is called for the
> inputtext component, the parent composite components are
> already ready, so it should be possible to execute the
> ValueExpressionAnalyzer without leading in a StackOverflow on
> postback.
>
> Feel free to ask me any questions about it.
>
> Regards,
> Thomas
>
>
>