James, Brilliant!!!
The EXCLUSIVE window state is exactly what I needed reminded of here, at least for the part of the story where the AngularJS frame rather than Respondr/Bucky provides the window dressing around the one primary portlet being rendered. I'll see how that goes. That has the makings of an interesting breakthrough. Kind regards, Andrew On Sun Jan 11 2015 at 4:36:38 PM James Wennmacher <[email protected]> wrote: > 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 - Unicon480.558.2420 > > > ------------------------------ > *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: >> [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 > > -- > > 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
