On 4/4/06, Richard Wallace <[EMAIL PROTECTED]> wrote:
The strategy I suggested works best if the component developer *does* know what "fallback" rendering approach to take. If you want that decision left up to the application developer instead, then the dual rendered flags thing is probably better.
Sure ... there's no restriction on how many properties on how many components are bound with the same _expression_. The _expression_ will get evaluated multiple times, of course, but that's not usually going to be an issue unless it has side effects or is unusually expensive to compute.
Using a single <h:panelGroup> like this is very useful in at least one scenario ... when you're defining the content of a facet. That's because a facet has to appear (to the owning component) to be a single component.
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.
The strategy I suggested works best if the component developer *does* know what "fallback" rendering approach to take. If you want that decision left up to the application developer instead, then the dual rendered flags thing is probably better.
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?
Sure ... there's no restriction on how many properties on how many components are bound with the same _expression_. The _expression_ will get evaluated multiple times, of course, but that's not usually going to be an issue unless it has side effects or is unusually expensive to compute.
> 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.
Using a single <h:panelGroup> like this is very useful in at least one scenario ... when you're defining the content of a facet. That's because a facet has to appear (to the owning component) to be a single component.
Rich
Craig
