> Really I prefer do the previous improvement and make vdl.buildView
> faster and cheaper, than do a component tree thread safe, because the
> later one has a lot more code and it is something really outside the >
> spec. I think that
> create a component tree is cheap, and in practice we should tr
Hi
2012/2/21 Martin Koci :
> Leonardo Uribe píše v Po 20. 02. 2012 v 17:51 -0500:
>> Hi
>>
>> Unfortunately we can't cache facelets generated unique ids into
>> ComponentTagHandlerDelegate because a tag handler can be used in many
>> views because a view is the result of execute many "facelet
>> c
Leonardo Uribe píše v Po 20. 02. 2012 v 17:51 -0500:
> Hi
>
> Unfortunately we can't cache facelets generated unique ids into
> ComponentTagHandlerDelegate because a tag handler can be used in many
> views because a view is the result of execute many "facelet
> compositions".
>
> In facelets ther
Hi
Unfortunately we can't cache facelets generated unique ids into
ComponentTagHandlerDelegate because a tag handler can be used in many
views because a view is the result of execute many "facelet
compositions".
In facelets there are two "hierarchical counters", one for
MARK_CREATED (FaceletConte
Same situation for clientId: in "stable" component tree is clientId
always the same (state saving depends on it)
unfortunately has UIComponent no method setClientId. But we can try set
it via reflexion and compare if it brings an improvement or not.
Currently getClientId() uses lazy init and invol
Hi,
in situation, where no build-time tags (c:if, co:foreach, ...) and no
ui:include src="#{}" are used (and no direct component.getChildren()
manipulation of course), builds VDL.buildView every time the same
component structure (same graph).
In this case compute myfaces some informations again
