I agree that other affected portlets need to be notified of changes.
As a summary, there are two proposals under discussion.
wrote on 04.02.2014 15:29:50:
Date: 04.02.14 15:35
Subject: [jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) -
Client Programming Model
Hi Scott, Neil, everyone,
finally I had time to look into the Ajax suggestions made by Neil and
others. Great work so far!
One part I am missing (perhaps I overlooked something. If so, please
Assuming the scenario, where you have two or more portlets. Portlet A
triggers an Ajax request, resulting in a Portlet event or any server
action which influences the state of Portlet A and B.
The Ajax response is sent back to Portlet A, where it can initiate a
partial rendering (for itself).
But how does Portlet B know that it has to be rendered? Should this be
In JSF, you as a programmer have to define explicitly where parts of the
page have to be re-rendered (by specifiying the render attribute).
For the portlet world, it would be more convenient of the other involved
Portlets would be re-rendered automatically if the request triggered by
Portlet influences their markup.
@Scott: I think in WebSphere a similar feature like this is implemented,
somewhere in the SSA (Server side aggregration) feature?
What do you think?
------ Originalnachricht ------
Von: "Martin Scott Nicklous"
Gesendet: 03.02.2014 09:40:46
Betreff: [jsr362-experts:] JSR 362 Ajax Proposal (alternate) - Client
>According to the portlet programming model, the event is equivalent to
>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
>However, if that same portlet reaches that same state through an event
>event and submit a separate resource request in order to retrieve the
>I think it would be better to have a regular programming interface on
>client. When the portlet state changes, the portlet gets notified, and
>update its UI appropriately obtaining data from the server as needed.
>An HTTP POST request is always passed to the server, since POST means
>resource on the server is to be created or updated. That means that
>never be a browser or HTTP proxy cache hit for the POST request, and
>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
>for display, since such data can be cached by the browser or by HTTP
>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
>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
>Also, the proposal would require specifying the message format returned
>client, which would be unnecessary under a different proposal.
>The event is not "personalized" for each target portlet, but all
>portlets get notified and have to contact the server to determine
>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
>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
>state without always contacting the server to check for a potential
>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
>full of non-JSF portlets.
[jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model
|andy . bosch||02/05/2014|
|Martin Scott Nicklous||02/05/2014|
|andy . bosch||02/10/2014|
|Martin Scott Nicklous||02/10/2014|