Note that even a slightly-less-sloppily written portlet that does check whether the current window state is DETACHED may not recognize SEPARATED’s similar characteristics, what with SEPARATED not having existed at the time all existing portlets were written. :)
But more to the point: this completely alternative external rendering approach, this sounds like it has potential, and synergy. Wasn’t there something about a servlet for rendering portlets? /portal/just_render_the_portlet_by_itself_aka_separated/fname ? Suppose uMobile could address portlets along those lines and for that matter something like that is useful for grabbing portlet markup to present embedded in an AngularJS frame? -Andrew > On Apr 17, 2015, at 3:49 AM, Anthony Colebourne > <[email protected]> wrote: > > Hi, > > The portlet spec has the concept of WindowStates and sometimes Portlets make > use of them. > > By using WindowStates as the mechanism to deliver content to external apps, > it means that one cannot fully make use of all window states within that > content. > > You might argue that this is an entirely appropriate use of WindowStates. The > point highlighted in the thread was that often Portelts are sloppily > developed and make assumptions about WindowState. > > A typical use case is for a portlet to change its window state at some point. > Well written portlets would check their current window state before doing > this (e.g. if SEPARATED then don't change or only change if current == > NORMAL). > > A completely alternative "external rendering" approach that didn't use > WindowStates and therefore could be made to support all window states would > not suffer from these "deficiencies". > > -- Anthohny. > > > On 17/04/15 01:05, James Wennmacher wrote: >> Hi Anthony. >> >> Thanks for bringing my attention to this thread. I'm not sure I fully >> follow it. Can you clarify for me what the deficiencies are? Thanks. >> >> James Wennmacher - Unicon >> 480.558.2420 >> >> On 04/14/2015 03:59 PM, Anthony Colebourne wrote: >>> Hi James, >>> >>> Now seems like an appropriate time to draw your attention to this thread. >>> http://jasig.275507.n4.nabble.com/Detached-WindowState-td4657565.html >>> >>> It highlights this deficiencies in the WindowState based approach to >>> getting content rendered for consumption in an external app. >>> >>> Thanks, >>> Anthony. >>> >>> >>> On 14/04/15 21:58, James Wennmacher wrote: >>>> A request to add a new window state came about due to Oakland which has >>>> a native uMobile app found that DETACHED window state which the uMobile >>>> app uses behaves differently with uPortal 4.1+. Refer to >>>> https://issues.jasig.org/browse/UP-4440. >>>> >>>> I plan to add a new window state SEPARATED which is like the old >>>> DETACHED window state. I'm OK with the name, but not jumping up for >>>> joy. It's fairly clear and consistent (at least as much as DETACHED >>>> was). Anyone have a better name? >>>> >>>> See issue for details and reasoning. >>>> >>> >> >> > > -- > 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
