[jsr362-experts:] JSR 362 Ajax Proposal (alternate) - Client Programming Model
- From: Martin Scott Nicklous <
- Subject: [jsr362-experts:] JSR 362 Ajax Proposal (alternate) - Client Programming Model
- Date: Mon, 3 Feb 2014 09:40:46 +0100
According to the portlet programming model, the event is equivalent to the
action in terms of semantics. When a portlet receives an event, it can
its state information just as it can if an action request is executed.
The client side programming model presented by the alternative proposal
different processing depending on whether an action is carried out or
the portlet state is changed through an event.
If the portlet executes an action, it submits a form through a partial
URL. That portlet receives a partial response containing markup or other
However, if that same portlet reaches that same state through an event
event and submit a separate resource request in order to retrieve the data
I think it would be better to have a regular programming interface on the
client. When the portlet state changes, the portlet gets notified, and can
update its UI appropriately obtaining data from the server as needed.
An HTTP POST request is always passed to the server, since POST means that
resource on the server is to be created or updated. That means that there
never be a browser or HTTP proxy cache hit for the POST request, and that
fragment returned in the partial action response won't be cached by the
browser or by the HTTP caching infrastructure.
So it would be better from a performance point of view if each portlet
whose state has changed uses a resource URL to retrieve any necessary data
for display, since such data can be cached by the browser or by HTTP cache
Another question is how does a portlet whose state has been updated get
notified about its new state?
I understand that according to the alternate proposal, the portlet issuing
partial action request is responsible for parsing a complicated XML
Parsing the return data might be easy for a JSF portlet, but I think it
lot of (unnecessary) work for a non-JSF portlet. A mistake in the portlet
Also, the proposal would require specifying the message format returned to
client, which would be unnecessary under a different proposal.
The event is not "personalized" for each target portlet, but all listening
portlets get notified and have to contact the server to determine whether
something needs to be done.
In addition, I understand that a broadcast event initiated by portlet A
contain the private & public parameters for portlet A, but not for portlet
and portlet C. But the private parameters for portlet A do not interest
B. And I don't understand how portlets B and C are supposed to obtain their
state without always contacting the server to check for a potential update.
My impression is that the alternate proposal, from the client-side
model point of view, might be a good fit for a JSF portlet issuing a
action request, but it looks to me like a less than optimal fit for a page
full of non-JSF portlets.