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,
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
o As opposed to /uPortal/api/portlet/{fname} which returns minor
portlet publishing info
o Including ID which would be from /uPortal/layout.json or
/uPortal/api/layout/v2/layout.json after
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:
o 200 - content returned in response body
o 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?
o 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.
o 304 - return this if supporting eTag (or If-Modified-Since but
I'm not sure this makes sense)?
o 401 - Unauthorized (need to authenticate)
o 403 - Forbidden for some reason, probably that it exists but
user doesn't have access to it
o 404 - for invalid portlet ID or URL (assuming URL at least gets
to the endpoint)
o 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.
--
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
