Hi,
So I think we really want these two worlds to collide in some way. I
absolutely agree that uPortal should be a client side app that ajaxies
back to the uPortal server.
Having special portlet modes/window states that allow portlets to
contribute plugins to the portal's client side app seems like a possible
route to investigate.
So portlets in regions must conform UI-wise to some portal vendor rules
to be eligible for use in a region. Portlets wishing to contribute to
the running client UI might not bootstrap their own client side context,
but opt to conform to some rules to plug-in their capabilities to
uPortal UI.
I see your problem; with all this client side stuff happening, how do
non 'uPortal compatible' portlets get their markup or mini client side
UI apps rendered?
With this kind of stuff I'm keen to understand whether Portlet spec 3
will offer any guidance?
-- Anthony.
On 07/01/15 21:47, Andrew Petro wrote:
Anthony,
All that's fair.
I'm coming at it a bit sideways in that I'm thinking about how to add
server-generated dynamic content to
https://github.com/UW-Madison-DoIT/angularjs-portal , of course.
Currently when our Beta users dive into a portlet, they bop over to our
forked-from-Respondr theme to render that portlet. And that's fine as
far as it goes, but it's a lot of XSLT machinery to do what has become a
very limited job (rendering one portlet with some chrome around it.)
There's also some annoyance in leaving and returning to what amounts
to a Single Page Application that renders our Beta landing page and the
not-portlet Beta functionality.
So. I'm thinking that if the framework knew how to render the markup of
one portlet without having to go through the whole rendering pipeline
XSLT stuff, as in, the kind of thing that would respond to an
asynchronous call for the portlet markup in a theme that rendered
portlets that way, well, hey, that's also exactly the kind of
asynchronous call that a Single Page Application front end could do to
simulate what we're currently getting out of forked-from-respondr
rendering maximized portlets. :) And then users would never leave the
AngularJS front end (while within our portal, anyway) and we'd only have
to implement sidebar chrome and so forth once and life would just be
cleaner all around.
Andrew
On Wed Jan 07 2015 at 3:39:34 PM Anthony Colebourne
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
A few years ago this sounded like a possible good way forward. These
days I'm less convinced by this. These days I like to develop Portlet
UIs in much the same way I develop servlet app UIs; I deliver the client
side application which calls back to its portlet origin for data via
ajax. In this model a framework-ajax loaded portlet would only really
serve to increase the number of requests.
Unless we could make this work 'transparently' then its possible that a
portlet developer would need to be aware at development time and code
for this type of rendering, therefore forcing the developer to alter
their development style to suite running in the portal.
Obviously there are use cases where is would be an advantage (WebProxy
content for example), but it might be that just adding this feature to
the WebProxyPortlet would be simpler?
Thanks,
Anthony.
On 07/01/15 20:40, Andrew Petro wrote:
> uPortal developers,
>
> Has anyone given thought to what it would look like to, at the
framework
> layer, make all the portlet markup render down to the browser
> asynchronously?
>
> Individual portlets have been developed to asynchronously render
their
> content, first rendering a loading... experience and then
replacing that
> with content once loaded. I think the email preview portlet or
so does
> this.
>
> But I'm wondering about implementing that generically at the
framework
> level. Instead of interpolating dynamic portlet content in the theme
> transform and having that HTML all cooked server side and fed down to
> the browser, instead generate the AJAXy placeholders that call
back to
> the server to get their portlet's markup when it's ready. (I
imagine if
> I understood Web Sockets I'd want to use them for some aspect of this
> and that would be better in some way.)
>
> Obviously, there are *better* experiences to be had by designing AJAX
> usages within individual units of content. Would need a way to opt
> portlets into or out of this magic handling.
>
> But still. Is there any potential in this idea? Anyone tried this?
>
> Kind regards,
>
> Andrew
>
> --
>
> You are currently subscribed to [email protected]
<mailto:[email protected]> as:
anthony.colebourne@manchester.__ac.uk
<mailto:[email protected]>
> To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/__display/JSG/uportal-dev
<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
<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
