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't think its part of the JSF spec, but as Craig has mentioned, its part of the XHTML standard. Not much can be done, however, until they modify that convertClientId method. That's the logical place to put it since its purpose is supposed to make the id acceptable for client-side rendering. sean On Sun, 9 Jan 2005 17:11:01 -0600, Heath Borders <[EMAIL PROTECTED]> wrote: > 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 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 doing this in the renderer. The id is being assigned > > by the component class itself (as we discused) but the enforcement is > > being handled by the renderer (as of now.) > > > > This is because this is really an HTML issue (that the id's be unique) > > and so it really should be up to the renderer. So I'm doing this in > > convertClientId. Ultimately I may have to move it somewhere else > > because of this issue but I'd like to keep there if possible. > > > > There must be a way to know whether the state is being restored or > > not. Somehow JSF knows because its only a problem every other time I > > load the page. > > > > Any other ideas? > > > > -- > -Heath Borders-Wing > [EMAIL PROTECTED] >
