t; ...
> If a component has been given an identifier, it must be unique in the
> namespace of the closest
> ancestor to that component that is a NamingContainer (if any).
>
>
> > -Original Message-
> > From: Heath Borders [mailto:[EMAIL PROTECTED]
> > Sent: T
: MyFaces Discussion
> Subject: Re: Need help with getViewRoot and attributes
>
>
> JSF doesn't require Ids to be unique over the whole tree,
> however, it does require that clientIds are unique throughout
> the component tree (I'm pretty sure).
>
>
> On M
JSF doesn't require Ids to be unique over the whole tree, however, it
does require that clientIds are unique throughout the component tree
(I'm pretty sure).
On Mon, 10 Jan 2005 18:55:57 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
> > Again, the renderer doesn't need to solve this problem be
> Again, the renderer doesn't need to solve this problem because it also
> concerns the how the tree is reconstructed. It is not just an (X)HTML
> problem. That's why the checking code should stay within the
> getClientId(FacesContext) method on the individidual UIComponents (but
> not on UICompo
Again, the renderer doesn't need to solve this problem because it also
concerns the how the tree is reconstructed. It is not just an (X)HTML
problem. That's why the checking code should stay within the
getClientId(FacesContext) method on the individidual UIComponents (but
not on UIComponentBase b
> Yes, that's ok ... it is the *client* ids that have to be unique,
> which is (in turn) why the default mechanism for calculating client
> ids concatenates them together when the parent component is a
> NamingContainer (as subview is).
So would you agree with my position that ideally the renderer
On Mon, 10 Jan 2005 13:50:02 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
> Hmmm. I've been hearing some conflicting information then.
>
> I thought the uniqueness is only needed per container. I thought it
> was technically ok to have two subviews (each with different id) and
> have each one
Hmmm. I've been hearing some conflicting information then.
I thought the uniqueness is only needed per container. I thought it
was technically ok to have two subviews (each with different id) and
have each one have a child component with the same id.
Is that ok?
sean
On Mon, 10 Jan 2005 18:55
> Faces does require that the clientId's are unique.
sure! that's why has also an id attribute
so you could use
e.g. inside of
and
result will be search:form
and foo:form
Regards,
Matthias
> When Faces restores the view, it uses the
> UIComponent.findComponent(String) method to try to res
Faces does require that the clientId's are unique.
When Faces restores the view, it uses the
UIComponent.findComponent(String) method to try to restore the
serialized components. If two components have the same clientId, then
it could cause the tree to be rendered incorrectly.
On Mon, 10 Jan 2005
> I'm not sure that convertClientId is the proper place for this logic.
>
> convertClientId seems like its there just to change the clientId to
> conform with specific renderer restrictions, independent of the
> UIComponent.
The way I see it, the uniqueness of the id's can be considered a
specifi
I'm not sure that convertClientId is the proper place for this logic.
convertClientId seems like its there just to change the clientId to
conform with specific renderer restrictions, independent of the
UIComponent.
I still think that you could put all the logic into the
getClientId(FacesContext)
This is what I have done for now. I'm going to nag the folks involved
with the specification to consider making UIComponent available to the
convertClientId method.
If you think about it, this kind of enforcement should really be part
of the default HTML renderer for the standard JSF tags. I don
Put the check inside the getClientId() call. If the id is forced,
make the check. If the check fails, log a warning and fall back to
the old way.
On Sun, 9 Jan 2005 18:08:39 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
> > How about this:
> > Why not store the Ids as a map mapping a clientI
> How about this:
> Why not store the Ids as a map mapping a clientId to a component.
> Then, you can just pull the component out of the map (if one exists),
> and check for equivalence. if they are equal, no problems.
Well the problem would be that I don't have a reference to the
component. I'm
How about this:
Why not store the Ids as a map mapping a clientId to a component.
Then, you can just pull the component out of the map (if one exists),
and check for equivalence. if they are equal, no problems.
On Sun, 9 Jan 2005 16:57:11 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
> I am
16 matches
Mail list logo
