[jsr362-observers:] [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF
- From: Neil Griffin <
- Subject: [jsr362-observers:] [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF
- Date: Wed, 30 Oct 2013 11:39:32 -0400
- List-id: <jsr362-experts.portletspec3.java.net>
(I was just about to send this message on the other thread you posted about
the minutes, but I think the AjaxActionURL idea you mention the email you
sent below might fit well with this)
In the minutes, you wrote:
> Scott's comment, not discussed directly in call: If I understood the gist
> of the above
> arguments correctly, the suggestion would be that we introduce capability
> that would
> allow stateful Ajax updates without running through the portlet
frameworks and also provide the ability to run through the
Frameworks like JSF provide the jsf.js library and corresponding f:ajax tag.
Component suites like PrimeFaces bypass this mechanism by providing the
primefaces.js library and corresponding p:ajax tag. So in both cases, either
jsf.js or primefaces.js expect to be in full control of issuing the
XmlHttpRequest. The way JSF portlet bridges integrate with this is by simply
uses for the Ajax postback.
Now, along that same line of thought, jQuery developers will want to perform
Ajax via jQuery.ajax()
... YUI3 developers will want to perform Ajax via Y.io()
... and DOJO developers will want to perform Ajax via dojo/request/xhr:
My idea would be to introduce a new type of portlet URL called
javax.portlet.PartialActionURL that would cause the portlet container to do
1. Execute the ACTION_PHASE for the portlet targeted by the PartialActionURL
2. Execute the EVENT_PHASE
3. Rather than return HTTP Status Code 301 (Redirect to a RenderURL), execute
the RENDER_PHASE (BUT ONLY FOR THE PORTLET TARGETED BY THE PartialActionURL).
The portlet container would not return a complete HTML document with all the
portlets, but rather only the the fragment of markup for the targeted portlet.
4. During the RENDER_PHASE, allow the portlet developer to render a
<script>...</script> that would participate in client side event
notifications. That way, interested portlets could listen to such events and
subsequently invoke an existing javax.portlet.ResourceURL in order to update
themselves. The developer would be free to use any type of client side
eventing mechanism, but we could provide a default mechanism via portlet.js.
I think that this approach could be integrated into JSF portlet bridges and
any changes to the portlet programming model, other than a new method called
On Oct 30, 2013, at 11:27 AM, Martin Scott Nicklous
> In the discussion we had last evening, I understood that there would be a
> desire for a portlet Ajax call that would update the state and return a
> response in one round trip. This would be in principle a stateful Ajax
> request or maybe stateful Ajax URL that would enable an XMLHttpRequest to
> carry out an update on the server, render the response, and provide the
> rendered partial response back to the client in one operation. I assume
> that this is the correct problem statement because Ajax requests that do
> not update the state are supported already through the resource request.
> (please correct me if I misunderstood).
> I can see how having such a URL might be good for JSF components, but I am
> really not convinced that it would fit in well with the portlet programming
> With portlets we have the lifecycle model where updates to the portlet (and
> portal) state are made during action or event processing, while the
> rendering is done in the separate render phase. A portlet can generate many
> different render URLs and embed them in the markup.
> For example, if your portlet shows paged output, you might have links
> containing render URLs (with parameters set appropriately) to move to a
> display different page within the portlet. Rendering doesn't change any
> portlet state, so render URLs can be bookmarkable and can participate in
> the browser history. Render URLS are submitted using an HTTP GET request.
> Action URLs, on the other hand, initiate changes to the portlet state. They
> are often used to submit forms - for example, a bank transaction form. They
> can't (shouldn't) be bookmarked, because the action might do something like
> debt your account, which you wouldn't want to happen multiple times. In
> fact, WebSphere prohibits reuse of an action URL in order to thwart replay
> attacks. Since they update the portal / portlet state, action URLs are
> submitted through an HTTP POST request.
> I think this is a good model - actually one of the beauties of the portlet
> programming model - that fits in well with REST. I don't think we want to
> break it.
> If we introduce something like an "AjaxActionURL" that carries out the
> action and returns a partially rendered response, how would that work
> If you don't have the stateful "AjaxAction" request run through the portlet
> lifecyle processing, you don't have eventing and shared render parameters.
> It would work like a servlet and would break the model.
> If we have it run the portlet lifecycle, the partial response would in
> general contain data for multiple portlets. It might happen that the action
> is initiated through a JSF portlet, but that there are other non-JSF
> portlets on the page that need updating as well. If there were only a
> single response for all of the portlets, the JSF portlet would receive that
> data it needs along with data for the other affected portlets as well. It
> might be able to deal with the data for itself, but what is it going to do
> with the data for the other portlets? Also, the JSF portlet will have to
> replace the "used" AjaxActionURL on the form that was submitted with a new
> one. I would imagine that this would be tough for the JSF Ajax support to
> In fact, I don't think it's even doable.
> We don't want to limit the types of portlets people mix on a page. So in
> general you might have a JSF portlet on the page along with a portlet that
> uses DoJo Ajax support for communicating with the portal, along with
> another that does Ajax in a roll-your-own manner. These various types of
> portlet might attach various types of listeners at various points within
> their markup.
> My first Ajax proposal #1 approach called for a central update mechanism
> that would go through the DOM tree making markup updates based on the id
> attribute for all of the portlets on the page. However, further thought
> showed that this would not be sufficient, because not only does the HTML
> have to be updated, but also the various handlers would potentially have to
> be put in their proper places again after the update. And also, some
> addition to the HTML and handlers. Besides that, proposal #1 made the
> assumption that we would always be dealing with a markup language like HTML
> that has id attributes that the central update module could search the DOM
> for, which isn't necessarily true, either.
> So I don't think any type of "central update module" approach for general
> portlets flies at all. I think we need a solution where each portlet
> updates itself as necessary, which is one of the characteristics of
> Proposal #2.
> well, and will need to communicate with the portal server in an Ajax
> I'm certainly not a JSF expert, but from what I have read, JSF assumes that
> controls communication with the server. If that is true, I don't yet
> understand how JSF would fit into a world of heterogenous portlets &
> widgets that have their own means of doing Ajax updates.
> It looks like there is more work to be done in this area ....