You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2005/07/01 04:30:39 UTC
Could use some help debugging sandbox
I've set up the sandbox with a separate sandbox webapp. The new
inputSuggest component that Matt and I worked on is in there. I'm
having a problem when I run inputSuggest.jsp. I get the following
error:
characters of component identifier (_id0:_id1_choice)must be a letter,
a digit, an underscore ('_'), or a dash ('-')! But component
identifier contains ":"
Note: I recently added to the debug statement so I could see the
actual ID being written that was the subject of the complaint.
What's interesting is that if I replace the new binaries with the old
myfaces.jar it runs fine. I'm thinking that something changed in the
myfaces implementation that is causing this. Any ideas?
TIA,
sean
Re: Could use some help debugging sandbox
Posted by Werner Punz <we...@gmx.at>.
Good thing that you replaced the colons with underscores, makes
things easier, once you want to recycle the component id in javascript.
I ran into some cases a while ago where I could not use the component id
directly but had to underscore the colons (not the
document.getObjectById that works, it was a different case, I cannot
remember now)
Werner
Grant Smith wrote:
> I think you basically have to implement getClientId(FacesContext
> context) with somthing that doesn't include a colon for the new
> component. As Matt says, we're probably being more spec-compliant lately.
>
>
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
Grant Smith wrote:
> klundge until I understand things better.
Klundge (C) Grant Smith 2005. Defn: Like a kludge, only worse.
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
3.1.1 I mean..
Grant Smith wrote:
> Hmm.. Does this mean that section 3.2.2 of the spec directly
> contradicts section 3.3.1 ?
>
> Craig ?
>
>
> Bruno Aranda wrote:
>
>> Hey, stop, the colon is what the NamingContainer uses, as stated in
>> section 3.2.2 of the spec.
>>
>> 'NamingContainer defines a public static final character constant,
>> SEPARATOR_CHAR, that is used to separate components of client
>> identifiers, as well
>> as the components of search expressions used by the findComponent()
>> method see
>> (Section 3.1.8 "Component Tree Navigation"). The value of this
>> constant must be a
>> colon character (":").'
>>
>> So, better to keep it ;-)
>>
>> Regards,
>>
>> Bruno
>>
>>
>
>
> .
>
Re: Could use some help debugging sandbox
Posted by John Fallows <jo...@gmail.com>.
Sean,
On 7/1/05, Sean Schofield <se...@gmail.com> wrote:
> The autogenerated id's do not have ':' in them anyways. The clientId
> has it but not the component id. In my case I was deriving the id of
> some hidden fields based on the client id which was a mistake. If I
> just derive off the component id everything is fine.
However, if you derive your hidden input field id from the component
id alone, then it will result in duplicated hidden input field ids
when the component is stamped by (say) a data component, or used with
the same id inside a different naming container - both of which are
legal in JSF.
If you need to reference the generated input field value, where the
name/id has one or more colons in it, then you can alwasy use the
[]-syntax rather than dot-syntax.
For example:
form['some:clientId:with:colons']
rather than
form.some:clientId:with:colons
Hope this helps.
Kind Regards,
John Fallows.
Re: Could use some help debugging sandbox
Posted by Sean Schofield <se...@gmail.com>.
Plus we should do some testing, etc. There are definitely some
improvements to be made. The sandbox is setup to be very similar to
tomahawk. So it won't matter much to the user when it moves out.
Just change the URI in the tag import statement on your jsp.
sean
On 7/2/05, Martin Marinschek <ma...@gmail.com> wrote:
> I would agree with Sean we make it a requirement for all sandbox
> components to have documentation attached before they move out of the
> sandbox, so as soon as this is done, move it in I would say!
>
> regards,
>
> Martin
>
> On 7/2/05, Grant Smith <gr...@marathon-man.com> wrote:
> > Sean,
> >
> > The inputSuggest component is great. I can confirm it works in Mozilla
> > and Firefox. There seems to be a small issue with Konqueror (KDE) in
> > that if you DOWN ARROW into the list, it just selects the first item,
> > and you then lose the rest of the items. However, I suspect that this is
> > just due to Konqueror's bad javascript interpreter with which I've had
> > problems with in the past.
> >
> > So now the obvious question is: How long before we boot it out of the
> > sandbox into Tomahawk ? I presume there is a prescribed testing /
> > waiting period ?
> >
> > Thanks and congrats to Matt and Sean for the first sandbox component!!
> >
> >
> >
> > Sean Schofield wrote:
> >
> > >Grant,
> > >
> > >The autogenerated id's do not have ':' in them anyways. The clientId
> > >has it but not the component id. In my case I was deriving the id of
> > >some hidden fields based on the client id which was a mistake. If I
> > >just derive off the component id everything is fine.
> > >
> > >sean
> > >
> > >ps. Thanks for looking into this. Give the new component a try if
> > >you're interested.
> > >
> > >
> > >
> > >
> >
> >
>
Re: Could use some help debugging sandbox
Posted by Sean Schofield <se...@gmail.com>.
> BTW, we should define a bylaw that defines this procedure. Should we
> make "voting out" mandatory?
+ 1
> -Manfred
sean
Re: Could use some help debugging sandbox
Posted by Manfred Geiler <ma...@gmail.com>.
2005/7/2, Martin Marinschek <ma...@gmail.com>:
> I would agree with Sean we make it a requirement for all sandbox
> components to have documentation attached before they move out of the
> sandbox, so as soon as this is done, move it in I would say!
***huch*** Does this in reverse mean that all components without
documentation outside of sandbox should go there now?! :-)
Ok, seriously: That's also my feeling. Having some docs and some
testing is the minimum requirement for sandbox components to move out
(or be voted out?). But we should not push too hard on the "how" and
"how much". Common sense is enough, IMHO.
BTW, we should define a bylaw that defines this procedure. Should we
make "voting out" mandatory?
-Manfred
>
> regards,
>
> Martin
>
> On 7/2/05, Grant Smith <gr...@marathon-man.com> wrote:
> > Sean,
> >
> > The inputSuggest component is great. I can confirm it works in Mozilla
> > and Firefox. There seems to be a small issue with Konqueror (KDE) in
> > that if you DOWN ARROW into the list, it just selects the first item,
> > and you then lose the rest of the items. However, I suspect that this is
> > just due to Konqueror's bad javascript interpreter with which I've had
> > problems with in the past.
> >
> > So now the obvious question is: How long before we boot it out of the
> > sandbox into Tomahawk ? I presume there is a prescribed testing /
> > waiting period ?
> >
> > Thanks and congrats to Matt and Sean for the first sandbox component!!
> >
> >
> >
> > Sean Schofield wrote:
> >
> > >Grant,
> > >
> > >The autogenerated id's do not have ':' in them anyways. The clientId
> > >has it but not the component id. In my case I was deriving the id of
> > >some hidden fields based on the client id which was a mistake. If I
> > >just derive off the component id everything is fine.
> > >
> > >sean
> > >
> > >ps. Thanks for looking into this. Give the new component a try if
> > >you're interested.
> > >
> > >
> > >
> > >
> >
> >
>
Re: Could use some help debugging sandbox
Posted by Martin Marinschek <ma...@gmail.com>.
I would agree with Sean we make it a requirement for all sandbox
components to have documentation attached before they move out of the
sandbox, so as soon as this is done, move it in I would say!
regards,
Martin
On 7/2/05, Grant Smith <gr...@marathon-man.com> wrote:
> Sean,
>
> The inputSuggest component is great. I can confirm it works in Mozilla
> and Firefox. There seems to be a small issue with Konqueror (KDE) in
> that if you DOWN ARROW into the list, it just selects the first item,
> and you then lose the rest of the items. However, I suspect that this is
> just due to Konqueror's bad javascript interpreter with which I've had
> problems with in the past.
>
> So now the obvious question is: How long before we boot it out of the
> sandbox into Tomahawk ? I presume there is a prescribed testing /
> waiting period ?
>
> Thanks and congrats to Matt and Sean for the first sandbox component!!
>
>
>
> Sean Schofield wrote:
>
> >Grant,
> >
> >The autogenerated id's do not have ':' in them anyways. The clientId
> >has it but not the component id. In my case I was deriving the id of
> >some hidden fields based on the client id which was a mistake. If I
> >just derive off the component id everything is fine.
> >
> >sean
> >
> >ps. Thanks for looking into this. Give the new component a try if
> >you're interested.
> >
> >
> >
> >
>
>
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
Sean,
The inputSuggest component is great. I can confirm it works in Mozilla
and Firefox. There seems to be a small issue with Konqueror (KDE) in
that if you DOWN ARROW into the list, it just selects the first item,
and you then lose the rest of the items. However, I suspect that this is
just due to Konqueror's bad javascript interpreter with which I've had
problems with in the past.
So now the obvious question is: How long before we boot it out of the
sandbox into Tomahawk ? I presume there is a prescribed testing /
waiting period ?
Thanks and congrats to Matt and Sean for the first sandbox component!!
Sean Schofield wrote:
>Grant,
>
>The autogenerated id's do not have ':' in them anyways. The clientId
>has it but not the component id. In my case I was deriving the id of
>some hidden fields based on the client id which was a mistake. If I
>just derive off the component id everything is fine.
>
>sean
>
>ps. Thanks for looking into this. Give the new component a try if
>you're interested.
>
>
>
>
Re: Could use some help debugging sandbox
Posted by Sean Schofield <se...@gmail.com>.
Grant,
The autogenerated id's do not have ':' in them anyways. The clientId
has it but not the component id. In my case I was deriving the id of
some hidden fields based on the client id which was a mistake. If I
just derive off the component id everything is fine.
sean
ps. Thanks for looking into this. Give the new component a try if
you're interested.
On 7/1/05, Grant Smith <gr...@marathon-man.com> wrote:
> I posted that a minute before Craig explained why (:) should NOT be
> allowed, so please ignore my previous suggestion.
>
> Grant Smith wrote:
>
> > Thanks Craig.
> >
> > Based on what Craig (and the spec :-) ) says, I think we need to
> > reconsider how we use UIComponentBase.setId(). If a component's ID is
> > generated automatically, we should not be calling isIdValid(). Either
> > that, or we need to explicitly allow the SEPARATOR_CHAR (:) to be
> > valid. I tend to favor the latter as it would be a simple change.
> >
> > Thoughts ?
> >
> >
> > Craig McClanahan wrote:
> >
> >> On 7/1/05, Grant Smith <gr...@marathon-man.com> wrote:
> >>
> >>
> >>> Hmm.. Does this mean that section 3.2.2 of the spec directly
> >>> contradicts
> >>> section 3.3.1 ?
> >>>
> >>> Craig ?
> >>>
> >>>
> >>
> >>
> >> There's a difference between the value of the *id* attribute in your
> >> source page (i.e. what 3.1.1 talks about) and the value that gets
> >> generated in the rendered output (which is what 3.2.2 talks about).
> >> The latter value is the *clientId* of the component, not the id, and
> >> therefore can include ":" characters when there is a NamingContainer
> >> involved.
> >>
> >> Note that the reason for having any restrictions in the first place is
> >> based on the fact that, in XHTML environments, the "id" attribute is
> >> declared to be of type ID, which imposes essentially the same set of
> >> restrictions of you want your source page, or the rendered output, to
> >> validate.
> >>
> >> Craig
> >>
> >>
> >>
> >>
> >>> Bruno Aranda wrote:
> >>>
> >>>
> >>>
> >>>> Hey, stop, the colon is what the NamingContainer uses, as stated in
> >>>> section 3.2.2 of the spec.
> >>>>
> >>>> 'NamingContainer defines a public static final character constant,
> >>>> SEPARATOR_CHAR, that is used to separate components of client
> >>>> identifiers, as well
> >>>> as the components of search expressions used by the findComponent()
> >>>> method see
> >>>> (Section 3.1.8 "Component Tree Navigation"). The value of this
> >>>> constant must be a
> >>>> colon character (":").'
> >>>>
> >>>> So, better to keep it ;-)
> >>>>
> >>>> Regards,
> >>>>
> >>>> Bruno
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> .
> >>
> >>
> >>
> >
> >
> > .
> >
>
>
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
I posted that a minute before Craig explained why (:) should NOT be
allowed, so please ignore my previous suggestion.
Grant Smith wrote:
> Thanks Craig.
>
> Based on what Craig (and the spec :-) ) says, I think we need to
> reconsider how we use UIComponentBase.setId(). If a component's ID is
> generated automatically, we should not be calling isIdValid(). Either
> that, or we need to explicitly allow the SEPARATOR_CHAR (:) to be
> valid. I tend to favor the latter as it would be a simple change.
>
> Thoughts ?
>
>
> Craig McClanahan wrote:
>
>> On 7/1/05, Grant Smith <gr...@marathon-man.com> wrote:
>>
>>
>>> Hmm.. Does this mean that section 3.2.2 of the spec directly
>>> contradicts
>>> section 3.3.1 ?
>>>
>>> Craig ?
>>>
>>>
>>
>>
>> There's a difference between the value of the *id* attribute in your
>> source page (i.e. what 3.1.1 talks about) and the value that gets
>> generated in the rendered output (which is what 3.2.2 talks about).
>> The latter value is the *clientId* of the component, not the id, and
>> therefore can include ":" characters when there is a NamingContainer
>> involved.
>>
>> Note that the reason for having any restrictions in the first place is
>> based on the fact that, in XHTML environments, the "id" attribute is
>> declared to be of type ID, which imposes essentially the same set of
>> restrictions of you want your source page, or the rendered output, to
>> validate.
>>
>> Craig
>>
>>
>>
>>
>>> Bruno Aranda wrote:
>>>
>>>
>>>
>>>> Hey, stop, the colon is what the NamingContainer uses, as stated in
>>>> section 3.2.2 of the spec.
>>>>
>>>> 'NamingContainer defines a public static final character constant,
>>>> SEPARATOR_CHAR, that is used to separate components of client
>>>> identifiers, as well
>>>> as the components of search expressions used by the findComponent()
>>>> method see
>>>> (Section 3.1.8 "Component Tree Navigation"). The value of this
>>>> constant must be a
>>>> colon character (":").'
>>>>
>>>> So, better to keep it ;-)
>>>>
>>>> Regards,
>>>>
>>>> Bruno
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> .
>>
>>
>>
>
>
> .
>
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
Thanks Craig.
Based on what Craig (and the spec :-) ) says, I think we need to
reconsider how we use UIComponentBase.setId(). If a component's ID is
generated automatically, we should not be calling isIdValid(). Either
that, or we need to explicitly allow the SEPARATOR_CHAR (:) to be valid.
I tend to favor the latter as it would be a simple change.
Thoughts ?
Craig McClanahan wrote:
>On 7/1/05, Grant Smith <gr...@marathon-man.com> wrote:
>
>
>>Hmm.. Does this mean that section 3.2.2 of the spec directly contradicts
>>section 3.3.1 ?
>>
>>Craig ?
>>
>>
>>
>
>There's a difference between the value of the *id* attribute in your
>source page (i.e. what 3.1.1 talks about) and the value that gets
>generated in the rendered output (which is what 3.2.2 talks about).
>The latter value is the *clientId* of the component, not the id, and
>therefore can include ":" characters when there is a NamingContainer
>involved.
>
>Note that the reason for having any restrictions in the first place is
>based on the fact that, in XHTML environments, the "id" attribute is
>declared to be of type ID, which imposes essentially the same set of
>restrictions of you want your source page, or the rendered output, to
>validate.
>
>Craig
>
>
>
>
>>Bruno Aranda wrote:
>>
>>
>>
>>>Hey, stop, the colon is what the NamingContainer uses, as stated in
>>>section 3.2.2 of the spec.
>>>
>>>'NamingContainer defines a public static final character constant,
>>>SEPARATOR_CHAR, that is used to separate components of client
>>>identifiers, as well
>>>as the components of search expressions used by the findComponent() method see
>>>(Section 3.1.8 "Component Tree Navigation"). The value of this
>>>constant must be a
>>>colon character (":").'
>>>
>>>So, better to keep it ;-)
>>>
>>>Regards,
>>>
>>>Bruno
>>>
>>>
>>>
>>>
>>
>>
>
>.
>
>
>
Re: Could use some help debugging sandbox
Posted by Matt Blum <mb...@gmail.com>.
But post-initial colons are supposed to be acceptable in XHTML, according to
the spec.
http://www.w3.org/TR/xhtml1/#C_8
So why aren't they permissible in JSF?
-Matt
On 7/1/05, Craig McClanahan <cr...@gmail.com> wrote:
>
> On 7/1/05, Grant Smith <gr...@marathon-man.com> wrote:
> > Hmm.. Does this mean that section 3.2.2 of the spec directly contradicts
> > section 3.3.1 ?
> >
> > Craig ?
> >
>
> There's a difference between the value of the *id* attribute in your
> source page (i.e. what 3.1.1 talks about) and the value that gets
> generated in the rendered output (which is what 3.2.2 talks about).
> The latter value is the *clientId* of the component, not the id, and
> therefore can include ":" characters when there is a NamingContainer
> involved.
>
> Note that the reason for having any restrictions in the first place is
> based on the fact that, in XHTML environments, the "id" attribute is
> declared to be of type ID, which imposes essentially the same set of
> restrictions of you want your source page, or the rendered output, to
> validate.
>
> Craig
>
>
> >
> > Bruno Aranda wrote:
> >
> > >Hey, stop, the colon is what the NamingContainer uses, as stated in
> > >section 3.2.2 of the spec.
> > >
> > >'NamingContainer defines a public static final character constant,
> > >SEPARATOR_CHAR, that is used to separate components of client
> > >identifiers, as well
> > >as the components of search expressions used by the findComponent()
> method see
> > >(Section 3.1.8 "Component Tree Navigation"). The value of this
> > >constant must be a
> > >colon character (":").'
> > >
> > >So, better to keep it ;-)
> > >
> > >Regards,
> > >
> > >Bruno
> > >
> > >
> >
> >
>
Re: Could use some help debugging sandbox
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/1/05, Grant Smith <gr...@marathon-man.com> wrote:
> Hmm.. Does this mean that section 3.2.2 of the spec directly contradicts
> section 3.3.1 ?
>
> Craig ?
>
There's a difference between the value of the *id* attribute in your
source page (i.e. what 3.1.1 talks about) and the value that gets
generated in the rendered output (which is what 3.2.2 talks about).
The latter value is the *clientId* of the component, not the id, and
therefore can include ":" characters when there is a NamingContainer
involved.
Note that the reason for having any restrictions in the first place is
based on the fact that, in XHTML environments, the "id" attribute is
declared to be of type ID, which imposes essentially the same set of
restrictions of you want your source page, or the rendered output, to
validate.
Craig
>
> Bruno Aranda wrote:
>
> >Hey, stop, the colon is what the NamingContainer uses, as stated in
> >section 3.2.2 of the spec.
> >
> >'NamingContainer defines a public static final character constant,
> >SEPARATOR_CHAR, that is used to separate components of client
> >identifiers, as well
> >as the components of search expressions used by the findComponent() method see
> >(Section 3.1.8 "Component Tree Navigation"). The value of this
> >constant must be a
> >colon character (":").'
> >
> >So, better to keep it ;-)
> >
> >Regards,
> >
> >Bruno
> >
> >
>
>
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
Hmm.. Does this mean that section 3.2.2 of the spec directly contradicts
section 3.3.1 ?
Craig ?
Bruno Aranda wrote:
>Hey, stop, the colon is what the NamingContainer uses, as stated in
>section 3.2.2 of the spec.
>
>'NamingContainer defines a public static final character constant,
>SEPARATOR_CHAR, that is used to separate components of client
>identifiers, as well
>as the components of search expressions used by the findComponent() method see
>(Section 3.1.8 "Component Tree Navigation"). The value of this
>constant must be a
>colon character (":").'
>
>So, better to keep it ;-)
>
>Regards,
>
>Bruno
>
>
Re: Could use some help debugging sandbox
Posted by Bruno Aranda <br...@gmail.com>.
Hey, stop, the colon is what the NamingContainer uses, as stated in
section 3.2.2 of the spec.
'NamingContainer defines a public static final character constant,
SEPARATOR_CHAR, that is used to separate components of client
identifiers, as well
as the components of search expressions used by the findComponent() method see
(Section 3.1.8 "Component Tree Navigation"). The value of this
constant must be a
colon character (":").'
So, better to keep it ;-)
Regards,
Bruno
2005/7/1, Bruno Aranda <br...@gmail.com>:
> I don't know why I always say 'release' implementation instead of
> 'reference'... :-P
>
> Bruno
>
> 2005/7/1, Bruno Aranda <br...@gmail.com>:
> > IMO it should be ok, but this is not a trivial change as many users
> > will need to update their javascript id references (if they are not
> > using forceId), and, moreover, the compatibility with the release
> > implementation will be lower as, AFAIK, it uses colons ':' as
> > separator chars...
> >
> > Bruno
> >
> > 2005/7/1, Grant Smith <gr...@marathon-man.com>:
> > > Grant Smith wrote:
> > >
> > > > Sean,
> > > >
> > > > I just committed a change to InputSuggestRenderer which MAY solve your
> > > > problem. If it doesn't, it means that the id is being prepended to by
> > > > something I don't understand. As it is, I don't see how colons are
> > > > being generated by UIViewRoot.createUniqueId(), so this might just be
> > > > a klundge until I understand things better.
> > > >
> > > > Let me know if it works
> > >
> > > OK,
> > >
> > > Here is what I now know:
> > >
> > > UIComponentBase uses NamingContainer.SEPARATOR_CHAR to build the id. I
> > > would like to propose changing
> > >
> > > public interface NamingContainer
> > > {
> > > public static final char SEPARATOR_CHAR = ':';
> > > }
> > >
> > > to
> > >
> > > public interface NamingContainer
> > > {
> > > public static final char SEPARATOR_CHAR = '_';
> > > }
> > >
> > > and removing all the
> > >
> > > component.getClientId(context).replaceAll(":","_")
> > >
> > > constructs scattered throughout the system. Any objections ?
> > >
> > >
> >
>
Re: Could use some help debugging sandbox
Posted by Bruno Aranda <br...@gmail.com>.
I don't know why I always say 'release' implementation instead of
'reference'... :-P
Bruno
2005/7/1, Bruno Aranda <br...@gmail.com>:
> IMO it should be ok, but this is not a trivial change as many users
> will need to update their javascript id references (if they are not
> using forceId), and, moreover, the compatibility with the release
> implementation will be lower as, AFAIK, it uses colons ':' as
> separator chars...
>
> Bruno
>
> 2005/7/1, Grant Smith <gr...@marathon-man.com>:
> > Grant Smith wrote:
> >
> > > Sean,
> > >
> > > I just committed a change to InputSuggestRenderer which MAY solve your
> > > problem. If it doesn't, it means that the id is being prepended to by
> > > something I don't understand. As it is, I don't see how colons are
> > > being generated by UIViewRoot.createUniqueId(), so this might just be
> > > a klundge until I understand things better.
> > >
> > > Let me know if it works
> >
> > OK,
> >
> > Here is what I now know:
> >
> > UIComponentBase uses NamingContainer.SEPARATOR_CHAR to build the id. I
> > would like to propose changing
> >
> > public interface NamingContainer
> > {
> > public static final char SEPARATOR_CHAR = ':';
> > }
> >
> > to
> >
> > public interface NamingContainer
> > {
> > public static final char SEPARATOR_CHAR = '_';
> > }
> >
> > and removing all the
> >
> > component.getClientId(context).replaceAll(":","_")
> >
> > constructs scattered throughout the system. Any objections ?
> >
> >
>
Re: Could use some help debugging sandbox
Posted by Bruno Aranda <br...@gmail.com>.
IMO it should be ok, but this is not a trivial change as many users
will need to update their javascript id references (if they are not
using forceId), and, moreover, the compatibility with the release
implementation will be lower as, AFAIK, it uses colons ':' as
separator chars...
Bruno
2005/7/1, Grant Smith <gr...@marathon-man.com>:
> Grant Smith wrote:
>
> > Sean,
> >
> > I just committed a change to InputSuggestRenderer which MAY solve your
> > problem. If it doesn't, it means that the id is being prepended to by
> > something I don't understand. As it is, I don't see how colons are
> > being generated by UIViewRoot.createUniqueId(), so this might just be
> > a klundge until I understand things better.
> >
> > Let me know if it works
>
> OK,
>
> Here is what I now know:
>
> UIComponentBase uses NamingContainer.SEPARATOR_CHAR to build the id. I
> would like to propose changing
>
> public interface NamingContainer
> {
> public static final char SEPARATOR_CHAR = ':';
> }
>
> to
>
> public interface NamingContainer
> {
> public static final char SEPARATOR_CHAR = '_';
> }
>
> and removing all the
>
> component.getClientId(context).replaceAll(":","_")
>
> constructs scattered throughout the system. Any objections ?
>
>
Re: Could use some help debugging sandbox
Posted by Sean Schofield <se...@gmail.com>.
I don't object but I'm curious about how the RI handles this. Doesn't
the RI use ':' with naming containers? If you have a component with
id = 'bar' inside a form with id 'bar' you get 'foo:bar' right? Isn't
that how things always worked?
sean
On 7/1/05, Grant Smith <gr...@marathon-man.com> wrote:
> Grant Smith wrote:
>
> > Sean,
> >
> > I just committed a change to InputSuggestRenderer which MAY solve your
> > problem. If it doesn't, it means that the id is being prepended to by
> > something I don't understand. As it is, I don't see how colons are
> > being generated by UIViewRoot.createUniqueId(), so this might just be
> > a klundge until I understand things better.
> >
> > Let me know if it works
>
> OK,
>
> Here is what I now know:
>
> UIComponentBase uses NamingContainer.SEPARATOR_CHAR to build the id. I
> would like to propose changing
>
> public interface NamingContainer
> {
> public static final char SEPARATOR_CHAR = ':';
> }
>
> to
>
> public interface NamingContainer
> {
> public static final char SEPARATOR_CHAR = '_';
> }
>
> and removing all the
>
> component.getClientId(context).replaceAll(":","_")
>
> constructs scattered throughout the system. Any objections ?
>
>
>
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
Grant Smith wrote:
> Sean,
>
> I just committed a change to InputSuggestRenderer which MAY solve your
> problem. If it doesn't, it means that the id is being prepended to by
> something I don't understand. As it is, I don't see how colons are
> being generated by UIViewRoot.createUniqueId(), so this might just be
> a klundge until I understand things better.
>
> Let me know if it works
OK,
Here is what I now know:
UIComponentBase uses NamingContainer.SEPARATOR_CHAR to build the id. I
would like to propose changing
public interface NamingContainer
{
public static final char SEPARATOR_CHAR = ':';
}
to
public interface NamingContainer
{
public static final char SEPARATOR_CHAR = '_';
}
and removing all the
component.getClientId(context).replaceAll(":","_")
constructs scattered throughout the system. Any objections ?
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
Sean,
I just committed a change to InputSuggestRenderer which MAY solve your
problem. If it doesn't, it means that the id is being prepended to by
something I don't understand. As it is, I don't see how colons are being
generated by UIViewRoot.createUniqueId(), so this might just be a
klundge until I understand things better.
Let me know if it works
Grant Smith wrote:
> I think you basically have to implement getClientId(FacesContext
> context) with somthing that doesn't include a colon for the new
> component. As Matt says, we're probably being more spec-compliant lately.
>
>
> Sean Schofield wrote:
>
>> I've set up the sandbox with a separate sandbox webapp. The new
>> inputSuggest component that Matt and I worked on is in there. I'm
>> having a problem when I run inputSuggest.jsp. I get the following
>> error:
>>
>> characters of component identifier (_id0:_id1_choice)must be a letter,
>> a digit, an underscore ('_'), or a dash ('-')! But component
>> identifier contains ":"
>>
>> Note: I recently added to the debug statement so I could see the
>> actual ID being written that was the subject of the complaint.
>>
>> What's interesting is that if I replace the new binaries with the old
>> myfaces.jar it runs fine. I'm thinking that something changed in the
>> myfaces implementation that is causing this. Any ideas?
>>
>> TIA,
>> sean
>>
>> .
>>
>>
>>
>
>
>
Re: Could use some help debugging sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
I think you basically have to implement getClientId(FacesContext
context) with somthing that doesn't include a colon for the new
component. As Matt says, we're probably being more spec-compliant lately.
Sean Schofield wrote:
>I've set up the sandbox with a separate sandbox webapp. The new
>inputSuggest component that Matt and I worked on is in there. I'm
>having a problem when I run inputSuggest.jsp. I get the following
>error:
>
>characters of component identifier (_id0:_id1_choice)must be a letter,
>a digit, an underscore ('_'), or a dash ('-')! But component
>identifier contains ":"
>
>Note: I recently added to the debug statement so I could see the
>actual ID being written that was the subject of the complaint.
>
>What's interesting is that if I replace the new binaries with the old
>myfaces.jar it runs fine. I'm thinking that something changed in the
>myfaces implementation that is causing this. Any ideas?
>
>TIA,
>sean
>
>.
>
>
>
Re: Could use some help debugging sandbox
Posted by Craig McClanahan <cr...@gmail.com>.
This requirement on component identifiers did *not* change between 1.0
and 1.1 ... but you'll have better luck finding it (in either case) if
you look in section 3.1.1 instead :-).
Craig
On 7/1/05, Matt Blum <mb...@gmail.com> wrote:
> According to the JSF 1.1 spec, section 3.3.1:
>
> Component identifiers must conform to the following rules:
> * They must start with a letter (as defined by the Character.isLetter()
> method) or underscore ('_').
> * Subsequent characters may be letters (as defined by the
> Character.isLetter() method), digits as defined by the Character.isDigit()
> method, dashes ('-'), and underscores ('_').
>
> It would seem that someone changed the implementation to better conform
> with the spec. I wasn't able to quickly find a copy of the 1.0 spec to see
> if that requirement had changed between 1.0 and 1.1.
>
> -Matt
>
>
> On 6/30/05, Sean Schofield <se...@gmail.com> wrote:
> > I've set up the sandbox with a separate sandbox webapp. The new
> > inputSuggest component that Matt and I worked on is in there. I'm
> > having a problem when I run inputSuggest.jsp. I get the following
> > error:
> >
> > characters of component identifier (_id0:_id1_choice)must be a letter,
> > a digit, an underscore ('_'), or a dash ('-')! But component
> > identifier contains ":"
> >
> > Note: I recently added to the debug statement so I could see the
> > actual ID being written that was the subject of the complaint.
> >
> > What's interesting is that if I replace the new binaries with the old
> > myfaces.jar it runs fine. I'm thinking that something changed in the
> > myfaces implementation that is causing this. Any ideas?
> >
> > TIA,
> > sean
> >
>
>
Re: Could use some help debugging sandbox
Posted by Matt Blum <mb...@gmail.com>.
According to the JSF 1.1 spec, section 3.3.1:
Component identifiers must conform to the following rules:
* They must start with a letter (as defined by the Character.isLetter()
method) or underscore ('_').
* Subsequent characters may be letters (as defined by the Character.isLetter()
method), digits as defined by the Character.isDigit() method, dashes ('-'),
and underscores ('_').
It would seem that someone changed the implementation to better conform with
the spec. I wasn't able to quickly find a copy of the 1.0 spec to see if
that requirement had changed between 1.0 and 1.1.
-Matt
On 6/30/05, Sean Schofield <se...@gmail.com> wrote:
>
> I've set up the sandbox with a separate sandbox webapp. The new
> inputSuggest component that Matt and I worked on is in there. I'm
> having a problem when I run inputSuggest.jsp. I get the following
> error:
>
> characters of component identifier (_id0:_id1_choice)must be a letter,
> a digit, an underscore ('_'), or a dash ('-')! But component
> identifier contains ":"
>
> Note: I recently added to the debug statement so I could see the
> actual ID being written that was the subject of the complaint.
>
> What's interesting is that if I replace the new binaries with the old
> myfaces.jar it runs fine. I'm thinking that something changed in the
> myfaces implementation that is causing this. Any ideas?
>
> TIA,
> sean
>