Anthony, I'd promised an analysis of how the new sticky profile code enables runtime-persistence-decision use cases. Here it is.
Recall that the problem we're solving here is that adopters might want users to be able to select a profile ad-hoc for a session and *not* persist that selection, as in actuating the "mobile site" link at the bottom of Universality renderings typical of folks who adopted mUniversality. (here's that link on production MyUW: http://cl.ly/image/0F0n1s0s3y3g ). Well. If an adopter wants the mobile theme selection to **never** persist, then the adopter can simply wire a different map of profile keys to profile fnames into the Sticky profile mapper, not including the mobile profile key in that map. Retain the SessionAttribute mapper with the map that does include the key-value pair. Then the consequence of : https://my.wisc.edu/portal/Login?profile=mobile will be to fire a ProfileSelectionEvent specifying profile key "mobile". The Session mapper handles the event, stores the selection of mUniversality into the session. The Sticky mapper handles the event, fails to see a valid mapping for the selection, so persists nothing. Then the login process consults the ChainingProfileMapper about what profile ought to be applied to this new session. The Session mapper should be first in the chain, and answers mUniversaity. Done. So the upshot is so long as the rule about whether a given profile selection persists is static ("mobile" never persists, "universality" always persists, say) then with configuration the proposed new sticky profile mapping code will Just Work to meet that use case. If however the rule is dynamic (sometimes should persist and shouldn't, ala your introduction of a new setDefault or oneTime request parameter to accompany the profile selection, well, the code proposed in the Sticky profiles pull request won't do that, but it provides good enough plugin points for an adopter to easily accomplish that locally. The ProfileSelectionEvent conveys the HttpServletRequest so a custom StickyIfSetDefaultRequestParameterIsTrueProfileMapper could condition its persistence on that parameter. Anyway, I'll be interested to see how adopters configure this and am hopeful that the more modular architecture will allow locally implementing and sharing profile mappers to get these algorithms just right. Kind regards, Andrew On Mon, Oct 20, 2014 at 9:04 AM, Andrew Petro <[email protected]> wrote: > There may well be interesting future use cases around profile > selection. Or perhaps we will enter a lovely future in which there's > just one responsive profile to handle all comers. I think that's > where MyUW is trying to get with its > forked-from-respondr-responsive-theme : even the amount of stickiness > complexity here is just a transitional feature to gently migrate folks > from Universality to Bucky. > > At the least I'll take a shot at articulating how an adopter would > achieve what you describe by plugging in to the extension points this > solution exposes. > > Kind regards, > > Andrew > > > On Sun, Oct 19, 2014 at 3:16 PM, Anthony Colebourne > <[email protected]> wrote: > > Hi, > > > > I was wondering whether stickiness in this regard should be a build time > or > > runtime choice? > > > > Might there be a use case where both might be required in a single > uPortal > > instance? The only case I can think of is switching from a dedicated > mobile > > theme to a desktop theme while using a mobile device. It's not the > strongest > > case for needing runtime sickness choice, but if these one use-case then > > there might be others! > > > > The thought that came to mind was > > /Login?profile=bucky&setDefault=true > > or > > /Login?profile=bucky&oneTime=true > > > > -- Anthony. > > > > > > > > On 17/10/14 19:01, Andrew Petro wrote: > >> > >> uPortal developers, > >> > >> MyUW has a need to make ad-hoc profile selection (via profile=bucky on > >> /Login) less "hoc" and more sticky-across-sessions. > >> > >> UP-4223 took a shot at this but didn't seem to work in MyUW. > >> > >> https://issues.jasig.org/browse/UP-4223 > >> > >> https://github.com/Jasig/uPortal/pull/416 > >> > >> Having looked into this a bit, I'd like to propose this alternative > >> implementation of making profile selection sticky: > >> > >> http://apetro.ghost.io/sticky-profiles/ > >> > >> I'm close to working code implementing this design and intend to offer > >> a Pull Request once it seems to be working locally. > >> > >> Feedback and design input welcome. > >> > >> Kind regards, > >> > >> Andrew > >> > > > > -- > > You are currently subscribed to [email protected] as: > > [email protected] > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
