>From: [EMAIL PROTECTED]
>
> The UIViewRoot unique id must be persisted to guarantee that no matter the state
> saving lifecycle of the component tree, that the UIViewRoot can always produce a
> unique ID, despite changes to the structure of the view at 'build time'.
>
> I understand what you are going for with Verbatims and unique ids-- but it
> requires repeatable order of evaluation. One or two if-statements could throw
> the whole order of comparison off. This is a major problem with sequence
> comparisons and accomodating document change.
>
>
> The UIViewRoot unique id must be persisted to guarantee that no matter the state
> saving lifecycle of the component tree, that the UIViewRoot can always produce a
> unique ID, despite changes to the structure of the view at 'build time'.
>
> I understand what you are going for with Verbatims and unique ids-- but it
> requires repeatable order of evaluation. One or two if-statements could throw
> the whole order of comparison off. This is a major problem with sequence
> comparisons and accomodating document change.
>
I see what you mean. If the structure of the tree can be dynamically changed,
then the simple sequence won't work.
> With JSP 2.1, we have JspIdConsumers which, by contract, assert that each JspTag
> will be assigned a unique id. This can be used instead in comparison since it's
> not order of evaluation dependent.
>
Oh, that's interesting. The "jsp:id" is used for components that don't have
component id's.
> With Facelets, we don't bother asserting uniqueness by Id for cleanup/transients
> and instead implement our own JspIdConsumer with an assignment to the
> AttributeMap. That value is instead used to determine duplication/cleanup,
> indifferent of the id assignments that the user or JSF impl provides. So
> instead of using the API's findComponent, we use a findComponent by Facelet
> Token ID.
>
I see but how do you handle caching of page fragments?
Thinking of how Clay caches. It loads a digested HTML or XML fragment into a graph of objects. These fragments can be pulled into various page compositions.
How do generate your Token ID and keep them from colliding as page fragments are reused?
Gary
>
> >From: [EMAIL PROTECTED]
> >
> >Declaring subviews and ajax regions is only a partial solution-- when JSF in
> fact
> >should be able to re-render any component without being explicitly declared as
> a
> >refreshable region (that's what we were pushing out of Facelets and JSF 1.2).
> >Ajax4Jsf does this by decoration of existing, non-ajax components and the JSF
> >1.2 invokeOnComponent (Martin, et. al) can do it for any component without
> >decoration in a very, very efficient manner.
>
> I have a related question that I'm sure you guys can help me understand. It has
> more
> to do with restoring the view and then recreating the components that are marked
> as
> transient. I think you would have similar issues with partial page rendering.
>
> There was a recent change in the myfaces UIViewRoot. The change was related > to the createUniqueId method. This component now persists the last generated
> id.
> From what I understand, JSF RI 1.2 behaves the same.
>
>
>
> What I'm unsure about is how to insert a new component (verbatim) into a
> restored tree.
> What is the best way to calculate an id that won't collide. It also requires a
> different method
> of inspecting the restored tree to see if a component needs to be recreated
> using the
> findComponent method.
>
> For a temporary solution with Clay, I create my own sequence that is reset each
> time the
> view is rendered and passed around in request scope. This new sequence doesn't
> use
> the UIViewRoot's method of generating a sequence but it seems to work.
>
> It appears that the myfaces JSP tags are doing a similar thing. The generated
> component
> id's don't appear to be generated using the UIViewRoot.
>
> Any insight would be appreciated.
>
> Gary
