Skip to main content

[jsr362-experts:] Some general thoughts on Ajax, Portlets and JSF

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-experts:] Some general thoughts on Ajax, Portlets and JSF
  • Date: Wed, 30 Oct 2013 16:27:13 +0100


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
model.

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
exactly?

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
handle.

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
JavaScript folks like to hold IDs that refer to particular elements in
arrays and other JavaScript objects, so these would have to be updated in
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.

On top of that, the portal theme will in general contain JavaScript as
well, and will need to communicate with the portal server in an Ajax
manner.

I'm certainly not a JSF expert, but from what I have read, JSF assumes that
it is in sort of a homogenous world where the JSF JavaScript module
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 ....

regards,
Scott



[jsr362-experts:] Some general thoughts on Ajax, Portlets and JSF

Martin Scott Nicklous 10/30/2013

[jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF

Neil Griffin 10/30/2013

[jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF

Martin Scott Nicklous 10/31/2013
 
 
Close
loading
Please Confirm
Close