It turns out that the reason Tips doesn't render atop mUniversality is that it's got hideInMobile set to true.
https://issues.jasig.org/browse/UP-4315 It'll happily render minimized -- its Controller is dumb as rocks and doesn't care what window state it is in. On Fri Nov 14 2014 at 4:30:09 PM James Wennmacher <[email protected]> wrote: > I had expected they would but they don't show. I think you are right > about the process of forcing everything minimized causing them to not > render. That looks like what I see in the pipeline logging. It would be > great to have all 3 fixed! (OK, maybe not tips :-) ). > > James Wennmacher - Unicon > 480.558.2420 > > On 11/14/2014 02:46 PM, Andrew Petro wrote: > > James, > > Those tips and alerts in mUniversality, very interesting. Do those > actually render? > > Here's what I get running current master and logging in with > ?profile=mobile: > > http://cl.ly/image/0o2e1o0n0U47 > > Should I be seeing tips and alerts? > > > > I think we're talking about the same approach. > > So, when I add > > <xsl:copy-of select="//channel[@fname = 'muniversality-beta-switcher']"/> > > into the mUniversality XSLT, that's a no-op, because > WindowStateSettingsStAXComponent exuberantly coerces that channel to > minimized, and then SimpleContentPortlet doesn't render markup with the > portal is minimized*, and so it ends up being no content. > > The change I'm looking at making is to give muniversality-beta-switcher > e.g. a way to block WindowStateSettingsStAXComponent's window state > coercion such that the channel will remain in NORMAL window state. > Applying that exemption to the portlet-definition for tips and alert might > allow those to render content on the mUniversality home too? > > Andrew > > * : I'm not sure whether it would matter even if SimpleContentPortlet > did know how to render minimized, since I imagine something in > muniversality doesn't bother trying to render portlets minimized anyway. :) > > > > On Fri Nov 14 2014 at 2:16:26 PM James Wennmacher <[email protected]> > wrote: > >> I'm not terribly familiar with all the contortions that happen with >> mUniversality rendering. However this seems reasonable. >> >> Another approach, one I might consider, is to modify muniversality.xsl >> to invoke a portlet in place in the header like is done with tips and >> alert >> ( >> https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/resources/layout/theme/muniversality/muniversality.xsl#L334 >> ). >> This way we aren't adding a hopefully-temporary change into the portlet >> definitions that is really intended to support a rather narrow use case >> (mUniversality). I believe the portlet content can still be a Simple >> Content portlet and manipulated via import entity files. I don't think >> you need to insert the markup directly into the XSLT (unless what I >> propose of invoking the portlet is what you meant by slamming it in). >> >> James Wennmacher - Unicon >> 480.558.2420 >> >> On 11/14/2014 11:37 AM, Andrew Petro wrote: >> > Speaking of innovating in mUniversality ( :) ), >> > >> > Need: >> > >> > Render a header under mUniversality inviting users to try the exciting >> > new based-on-Respondr "Bucky" profile instead. >> > >> > (Screenshot: http://cl.ly/YXJv ) >> > >> > There's a few ways that could be implemented, but the preferred way is >> > using a Simple Content Portlet since that's the way this feature works >> > under Universality and this allows tweaking the header content and >> > which users see it by manipulating importable entity files (instead >> > of, say, slamming the markup directly into the mUniversality XSLT.) >> > >> > Problem: >> > >> > mUniversality has the stylesheet parameter >> > "dashboardForcedWindowState" set such that non-targeted portlet >> > windows are coerced to minimized window state (as implemented in the >> > WindowStateSettingsStAXComponent rendering pipeline component). This >> > is desirable for the one-portlet-at-a-time navigation pattern of >> > mUniversality, but it breaks sneaking a little content into the page >> > via a portlet inclusion. >> > >> > Expected solution: >> > >> > Add an optional "immuneToDashboardForcedWindowState" parameter to >> > portlet definitions and nuance WindowStateSettingsStAXComponent to >> > refrain from coercing the window state of portlets with that parameter >> > set to true. >> > >> > Floating this idea via email to invite feedback, of course. >> > >> > 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 >> > -- > > 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 > > -- 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
