myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: Browser based component decisions
Date Tue, 04 Apr 2006 19:08:19 GMT
On 4/4/06, Richard Wallace <rwallace@thewallacepack.net> wrote:
>
> Craig McClanahan wrote:
> > On 4/4/06, *Richard Wallace* <rwallace@thewallacepack.net
> > <mailto:rwallace@thewallacepack.net>> 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

Mime
View raw message