Re: [uportal-dev] uPortal API endpoint for returning portlet markup (aka exclusive window_state alternative) for Rich JS UI and uMobile
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 jwennmac...@unicon.net 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-cache60/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 uportal-dev@lists.ja-sig.org as:
awi...@unicon.net
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] uPortal API endpoint for returning portlet markup (aka exclusive window_state alternative) for Rich JS UI and uMobile
This will be a great enhancement to the uPortal REST API, nice write up James!
There may be some merit in having it be more abstract like the canonical filter
(eg /p/fname). UW's use case for that is in our favorites list we only allow 1
per fname, granted once it is in the layout we do have the node id. However,
another use case is when someone launches the portlet directly without having
it in there layout.
I totally agree the 302 should never happen to the home. Maybe just a 400 level
error with a object doesn't exist therefore it is not message or something.
Thanks,
Tim Levett
tim.lev...@wisc.edu
MyUW-Infrastructure
From: bounce-41491308-70367...@lists.wisc.edu
bounce-41491308-70367...@lists.wisc.edu on behalf of James Wennmacher
jwennmac...@unicon.net
Sent: Thursday, May 28, 2015 4:15 PM
To: uportal-dev@lists.ja-sig.org
Subject: [uportal-dev] uPortal API endpoint for returning portlet markup (aka
exclusive window_state alternative) for Rich JS UI and uMobile
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
* 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 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:
* 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-cache60/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 uportal-dev@lists.ja-sig.org as:
tim.lev...@wisc.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal
[uportal-dev] uPortal API endpoint for returning portlet markup (aka exclusive window_state alternative) for Rich JS UI and uMobile
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-cache60/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 uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
