You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Richard Wallace <rw...@thewallacepack.net> on 2006/04/04 18:18:46 UTC
Browser based component decisions
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?
Thanks,
Rich
Re: Browser based component decisions
Posted by Adam Winer <aw...@gmail.com>.
... which is all EL-accessible, so fun things like:
rendered="#{adfFacesContext.agent.agentName == 'gecko'}"
or
rendered="#{adfFacesContext.agent.capabilities.dom == 'level2'}"
rendered="#{adfFacesContext.agent.capabilities.accessKeys}"
... all work.
-- Adam
On 4/4/06, Matthias Wessendorf <mw...@gmail.com> wrote:
> > friendly to have the component do its own check on user agent, and emit the
>
> The incoming stuff from ADF Faces donation contains more comfortable
> stuff regarding UserAgent.
>
> AdfFacesContext afc = AdfFacesContext.getCurrentInstance();
> Agent agent = afc.getAgent();
>
>
> You may take a look ;-)
>
> -Matthias
>
>
> > correct kind of markup accordingly. 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.
> >
> >
> > > Thanks,
> > > Rich
> > >
> >
> >
> > Craig
> >
> >
>
>
> --
> Matthias Wessendorf
> Zülpicher Wall 12, 239
> 50674 Köln
> http://www.wessendorf.net
> mwessendorf-at-gmail-dot-com
>
Re: Browser based component decisions
Posted by Matthias Wessendorf <mw...@gmail.com>.
> friendly to have the component do its own check on user agent, and emit the
The incoming stuff from ADF Faces donation contains more comfortable
stuff regarding UserAgent.
AdfFacesContext afc = AdfFacesContext.getCurrentInstance();
Agent agent = afc.getAgent();
You may take a look ;-)
-Matthias
> correct kind of markup accordingly. 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.
>
>
> > Thanks,
> > Rich
> >
>
>
> Craig
>
>
--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com
Re: Browser based component decisions
Posted by Craig McClanahan <cr...@apache.org>.
On 4/4/06, Richard Wallace <rw...@thewallacepack.net> wrote:
>
> Craig McClanahan wrote:
> > On 4/4/06, *Richard Wallace* <rwallace@thewallacepack.net
> > <ma...@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
Re: Browser based component decisions
Posted by Richard Wallace <rw...@thewallacepack.net>.
Craig McClanahan wrote:
> On 4/4/06, *Richard Wallace* <rwallace@thewallacepack.net
> <ma...@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. 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
Re: Browser based component decisions
Posted by Craig McClanahan <cr...@apache.org>.
On 4/4/06, Richard Wallace <rw...@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. 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.
Thanks,
> Rich
>
Craig