[jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model
- From: Martin Scott Nicklous <
- Subject: [jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model
- Date: Tue, 4 Feb 2014 17:19:14 +0100
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
> correct me):
> 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,
> it is
> 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
> Programming Model
> >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
> >to display.
> >However, if that same portlet reaches that same state through an event
> >event and submit a separate resource request in order to retrieve the
> >for display.
> >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
> >would be
> >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.