Craig McClanahan wrote:
On 4/4/06, *Richard Wallace* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hey all,
I'm looking at trying to add some more advanced UI elements to a
webapp
I'm developing. One thing that I'm concerned about is that this is an
app that will be used by the general public, not just in-house. That
means I have no control over the OS or browser used to access the
site.
Naturally I want as many people as possible to be able to access the
site. So I need to do some kind of selection process for when to
display the cool components and when to display the regular
components.
My use case at the moment is that I'm trying to replace a set of radio
buttons with a slider, the one from Yahoo!s library. I haven't
created
the JSF component yet and before I invest too much time into it I
want
to determine if it's feasible and how hard it is to do this kind of
browser based component usage decision making.
Could it be something as simple as:
<h:panelGroup rendered="#{browser.coolComponentCapable }">
<rw:inputSlider ...>
</h:panelGroup>
<h:panelGroup rendered="#{!browser.coolComponentCapable}">
<h:selectOneRadio ...>
</h:panelGroup>
Or is there a better way?
If you're writing the inputSlider component yourself, it would be more
user friendly to have the component do its own check on user agent,
and emit the correct kind of markup accordingly.
We had thought about that, but there's not always going to be a clear
"if you can't use the slider, use this component instead." I mean, in
my situation I want to be able to use radio buttons, but that wouldn't
work if the slider moves in increments smaller than the tick marks. In
that situation you could wind up with dozens of radio buttons, so you
may want to provide a dropdown or something else entirely. I suppose
the question I should ask is: Can 2 components be bound to the same
backing bean property if one of them is not rendered and will that cause
any problems, such as the non-rendered component overwriting the value
set by the rendered component?
If you don't have control over the components, then what you describe
will work -- but you don't need separate panelGroup elements:
<h:panelGroup>
<rw:inputSlider rendered="#{browser.coolComponentCapable}" .../>
<h:selectOneRadio rendered="#{not
browser.coolComponentCapable}" .../>
</h:panelGroup>
Or, if you don't need the parent to think this is a single component,
just dispense with the panel group entirely.
You're right, of course. Don't know why I thought I needed to have them
wrapped in panel groups. Oh well.
Rich
