I drafted a long response to this, but rather than sending that I think what I really need to do is articulate alternative vision better. Will do.
Short version: > I absolutely agree that uPortal should be a client side app that ajaxies back to the uPortal server. This is the very most important part of this thread. *Agreement, very broadly, on vision for a uPortal that provides more compelling user experiences by being a rich client-side app that relies upon the uPortal server. Awesome. Let's do that.* I suspect that in your mind that uPortal server is doing more with Portlets than it is in my mind, but presumably those are implementation details we can work out. :) > With this kind of stuff I'm keen to understand whether Portlet spec 3 will offer any guidance? Having sat on some Portlet 3 spec calls, I'm willing to be proven wrong, but I expect the Portlet 3 spec isn't going to provide guidance I'll want to follow. My impression was a lot of complexity, a lot of JSF, a lot of considerations that I just don't think are interesting or worthwhile or helpful. I'm keen to not pursue Portlet spec 3 and to do something better instead. Kind regards, Andrew On Wed Jan 07 2015 at 4:46:56 PM Anthony Colebourne < [email protected]> wrote: > 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 > -- 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
