Folks, I just created a PR for this feature: https://github.com/Jasig/uPortal/pull/562 <https://github.com/Jasig/uPortal/pull/562>
It doesn’t have all the bells & whistles covered in the discussion so far, but it does cover the basic, 80% case. drew > On May 28, 2015, at 2:15 PM, James Wennmacher <[email protected]> wrote: > > For the Rich-JS Angular uPortal front-end we are working on, we need to > create a uPortal API for returning portlet markup without using the current > EXCLUSIVE window-state strategy. As Anthony elaborated in > http://jasig.275507.n4.nabble.com/Name-for-new-window-state-that-was-like-DETACHED-td4665156.html > > <http://jasig.275507.n4.nabble.com/Name-for-new-window-state-that-was-like-DETACHED-td4665156.html>, > this (mis)use of Window State has some negative ramifications. We are > finding much the same. > > I am planning on following Andrew P's excellent idea (also in the above > thread) of creating a uPortal REST endpoint that returns the markup for a > single portlet, effectively like EXCLUSIVE mode without actually setting or > using the Window State. I want to discuss and collaborate on this feature as > I see it having broad applicability, minimally the two rich JS UIs and > uMobile. > > I haven't dug into the code details yet so I'm sure I'll find a few things > that might require some changes, but I wanted to present my overall thoughts > first for community feedback: > endpoint is /uPortal/api/portlet/{fname}.{ID}/exclusive > As opposed to /uPortal/api/portlet/{fname} which returns minor portlet > publishing info > Including ID which would be from /uPortal/layout.json or > /uPortal/api/layout/v2/layout.json > afterhttps://issues.jasig.org/browse/UP-4438 > <https://issues.jasig.org/browse/UP-4438> is processed. Including ID since a > portlet can appear multiple times on a page so fname is not sufficient. > Must return the markup as response body. Failure to return markup should > return appropriate HTTP error code. Should never return a 302. I propose: > 200 - content returned in response body > 204 - no content (I think it is better the portal definitively indicates no > content). An example of this might be when a portlet is minimized or has no > content? > 302 - A poorly formed URL that goes into uPortal would do the normal 302 to a > uPortal landing page, but I consider this a client-side error we probably > shouldn't try to prevent. > 304 - return this if supporting eTag (or If-Modified-Since but I'm not sure > this makes sense)? > 401 - Unauthorized (need to authenticate) > 403 - Forbidden for some reason, probably that it exists but user doesn't > have access to it > 404 - for invalid portlet ID or URL (assuming URL at least gets to the > endpoint) > 500 - for portlet throwing an error, etc. > markup returned in body of response. If portlet supports RENDER_HEADERS, > perhaps this should be the combined RENDER_HEADERS plus content > (RENDER_HEADERS content first of course). > Questions: > Should the HTTP Cache headers respect the portlet cache parameters; e.g. if > portlet's entry in portlet.xml had <expiration-cache>60</expiration-cache> > should the HTTP cache headers indicate a 60 second cache time? I think not > since an Action request should invalidate the cache. The JS UI could figure > that out, but the browser could not. If we always send an eTag and maybe > If-Modified-Since on the response and allow uPortal to intelligently manage > the caching primarily using its existing render output cache mechanism, I > think this would be as good as we need. > Do we need to allow for ?refresh=true to force invoking the portlet and not > using cached render output? I don't know of a use case for this at this > point. > Potential future expansions: > Create an endpoint to return content for a list of portlets or all portlets > on a specific tab > I welcome your thoughts on this idea. Written up as > https://issues.jasig.org/browse/UP-4478 > <https://issues.jasig.org/browse/UP-4478>. > -- > James Wennmacher - Unicon > 480.558.2420 > -- > > 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
