I suggest making this about two things.
One thing is the API between portal and portlets.
Thing 2 is how the portal implements fulfilling that API.
I think what's going on here is uPortal exposed an API whereby portlets
could get the theme name
request.getProperty(themeNameProperty);
and that used to be a useful thing, what with portlets comparing that theme
name to decide which views to use. We'd been calling it isMobile vs not
isMobile (desktop?), but maybe what was really going on there was
**theme**-specific views. Views tailored to look good under mUniversality
and Universality.
And maybe there's a continued place for that. It's probably not actually
true that portlets can generate generic markup that looks good under all
possible themes -- portlets are going to look a lot better if they can
tailor their markup to the theme they're running under, probably. Maybe
this gets at a migration path for starting to use respondr's Bootstrappy
goodness when available but continuing to support Universality for a while?
Interestingly, this feature might allow a place like MyUW that has forked
respondr quite a bit and so has something with its own name ("bucky") to
cleanly have portlets select different JSPs that are tailored to "bucky".
If portlet namespacing JSPs by theme name was implemented well, well,
MyUW's overlay on those portlets could consist only of adding the new
Bucky-tailored JSPs.
Anyway.
And then there's this other concept, whether the browser is roughly
"mobile" flavored. And maybe what we're discovering here is that portlets
want to know that. Okay. If so, I think the portal should be figuring
that out once as well as it can, and then exposing that fact to portlets
via a well-defined API. Something like
request.getProperty("mobileness");
and uPortal implements that property on the portlet requests, setting it to
some well-defined values. Maybe "true" "false" or "dunno" would get the
abstraction about right.
Anyway.
And then, to the extent that portlets wanted to choose their views or
markup or styles or other stuff depending upon a mobileness abstraction
rather than a theme name abstraction, well, then they could do it, even
under repondr where all comers get the same theme name. :)
And then we can have interesting explorations of how best to implement
fulfilling that API portal-side. Probably something pluggable and
configurable. Maybe use spring.io device detection. Maybe keep doing our
lovingly hand crafted user-agent regular expression matching. Maybe do
whatever it was that Steve Swinsburg was trying to get me to understand in
that other thread. :)
I do think breaking it up this way makes some sense -- the portal seems to
usually be the right architectural layer to be making a mobileness
determination, with the portlets usually consuming a simpler abstraction
rather than themselves trying to compute the mobileness of the request.
Rather than each portlet figuring it out for themselves.
Then in the near term MyUW's Courses portlet implementation might choose
view implementations based on the mobileness abstraction, with the
mobile-tailored JSPs for mobile devices and the desktop-tailored JSPs for
others. And perhaps in the longer term the theme-name abstraction would
actually be better, perhaps with a transition period where the portlet's
existing mobile JSPs serve the mUniversality theme, the existing desktop
JSPs serve the Universality theme, and shiny new responsive Bootstrap-using
JSPs serve the Bucky theme. Depending how the timeline works out between
Courses portlet improvement and Universality / mUniversality retirement.
Kind regards,
Andrew
On Tue Jan 06 2015 at 2:51:37 PM Tim Levett <tim.lev...@wisc.edu> wrote:
> Hi Devs,
>
>
> We came across an interesting problem and I'm curious if anyone else has
> had this issue. We are using the portlet-utils project in the
> CoursesPortlet and we use the method
> https://github.com/Jasig/portlet-utils/blob/master/portlet-mvc-util/src/main/java/org/jasig/portlet/utils/mvc/ThemeNameViewSelectorImpl.java#L30
> a lot to decide to show mobile based portlets. This uses themes to
> determine mobile or not. Now that we are on respondr which is used for
> mobile and desktop it is always showing desktop. Really we should do
> something like the Spring.io project
> https://spring.io/guides/gs/device-detection/ but that doesn't seem to
> play nice with portlets.
>
>
> Does anyone have an alternative method/example to figure out mobile or
> desktop on the server side with portlets?
>
>
> ​Thanks in advance. Happy new year!
>
>
> Tim Levett
> tim.lev...@wisc.edu
> MyUW-Infrastructure
> https://calendar.wisc.edu/share/u/tim.lev...@wisc.edu/dr(-14,30)
>
> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> apetro.li...@gmail.com
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
