Andrew does the Exclusive window state provide you with what you need (though may need to be streamlined for performance)? It would at least provide the markup. Since some of the markup would be javascript to execute that might be a bit dicey, but I thought uPortal does have a way to let you request just a single portlet's markup.
James Wennmacher - Unicon 480.558.2420 ----- Original Message ----- From: "Andrew Petro" <[email protected]> To: [email protected] Sent: Wednesday, January 7, 2015 2:47:12 PM Subject: Re: [uportal-dev] AJAX all the portlets 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] > 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] as: > anthony.colebourne@manchester. ac.uk > 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 -- 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
