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] <mailto:[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]
>     <mailto:[email protected]> as: [email protected]
>     <mailto:[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]
>     <mailto:[email protected]> as: [email protected]
>     <mailto:[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

Reply via email to