> So, back to my original question: If we were to override the
> Renderer.convertClientId() method to replace colons with (say)
> an underscore character, would that break anything else in JSF?
You could break a lot, and will almost definitely encounter problems.
Even if code was responsible and used the constant, you will problems.
This is because the value is a constant value and therefore will be
optimized by compilers
Example:
public interface NamingContainer {
public static final char SEPARATOR_CHAR = ':';
}
public class MyRenderer {
...
stringBuffer.append(NamingContainer.SEPARATOR_CHAR);
...
}
This gets compiled down to:
stringBuffer.append(':');
This means that you will have to recompile all of your 3rd party jars
from source that has a chance of referring to
NamingContainer.SEPARATOR_CHAR. This is assuming that people didn't
just use ':' anywhere in their code, since
NamingContainer.SEPARATOR_CHAR is not configurable according to the
JSF spec, they are not in danger of bugs (as JSF defines it as being a
colon, always).
Using an underscore would be a very bad idea as well, as it is a valid
character in the components ID. You would have to use a character that
is illegal in a JSF ID.
See http://tinyurl.com/3xpalb for information on what is valid for an ID.
I really don't think you want to alter NamingContainer.SEPARATOR_CHAR.
It is much more work than just using CSS classes in your code, and CSS
classes are much more maintainable in the long run (you can change
component IDs without breaking your CSS code)
If you really want to use CSS IDs, I would suggest using DIV and SPAN
tags around your components:
<div id="myDiv">
<h:outputText value="#{...}"/>
</div>
<style type="text/css">
#myDiv { color: red; }
</style>
This way you avoid referencing JSF IDs entirely.
-Andrew
> And is underscore a reasonable replacement for colon or would
> you suggest a different character?
>
> Thanks,
> Bryan
>
> Andrew Robinson wrote:
> > Actually colon's are legal in CSS, just not supported by Microsoft (go
> > figure), they just need to be escaped for the "real" browsers.
> >
> > I would suggest using style classes instead of IDs and just give
> > components unique style classes. I know it isn't the same, but it is
> > much less risky than changing the naming separator.
> >
> > Also, if you change your layout (id of a naming container), you would
> > have to change a large amount of CSS code if you were using client
> > IDs.
> >
> > Almost all components support styleClass, so that shouldn't be an issue at
> > all
> >
> > -Andrew
> >
> > On 8/7/07, Bryan Basham <[EMAIL PROTECTED]> wrote:
> >
> >> Hello,
> >>
> >> There is a well-known problem with JSF's choice of using a colon
> >> as the NAMING_SEPARATOR character: The CSS standard does
> >> not work well with HTML IDs that include a colon in the name.
> >> So for example, if you try to style a specific input element...
> >> <h:form id='x'>
> >> <h:inputText id='name' ... />
> >> </h:form>
> >>
> >> ...with a CSS file entry...
> >> input#x:name { /* style configuration */}
> >>
> >> This is illegal in CSS. As I said, this is well known. Here are a few
> >> links that a co-worker discovered in his investigation:
> >>
> >> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=161
> >> http://www.nabble.com/Colons-in-component-ids-tf1476983.html#a4015739
> >> http://wiki.apache.org/myfaces/css_component_ids
> >>
> >> My team is investigating a work-around for this. I read through
> >> the UIComponentBase.getClientId() code and it is clear that we
> >> cannot alter the NAMING_SEPARATOR character. However,
> >> I did notice the component's renderer is given the opportunity to
> >> convert the name before it is stored (and returned from the getClientId
> >> method). The base Renderer.convertClientId method simply returns
> >> the passed in string; no conversion.
> >>
> >> Has anyone tried to override this convertClientId method to change the
> >> colon to some other, CSS-compatible character? If so, which character
> >> did you use to replace the colon? And did this conversion cause other
> >> problems within the JSF framework itself?
> >>
> >> The PROs are clear: enables component-specific styling. The CONs are
> >> not so obvious, but the biggest "gotcha" I have found is that if you use
> >> standard JSF components, you must override their renderers to support
> >> the conversion. Can anyone think of other gotchas?
> >>
> >> Regards,
> >> Bryan
> >>
> >>
> >>
>
>
