Skip to main content

[jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model

  • From:
  • To:
  • Subject: [jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model
  • Date: Wed, 05 Feb 2014 10:34:01 +0000

Hi Scott, Neil,

I have read the document
http://www.portletfaces.org/downloads/jsr-362/jsr-362-ajax-proposal-alternate.pdf
from Neil quite closely.
I like the general approach, but would go one or two steps further.

In chapter 7 it is mentioned, that after an Ajax response, all registered portlet
event listeneres will be informed. So you have to define manually your own
event listener. That is fine for the Portet that triggered the Ajax request, as the
response can be interpreted in various ways.

In chapter 8 it is mentioned, that the response is only limited to the Portlet that
triggered the Ajax request. I would like the feature, that affected Portlets would
be re-rendered automatically without having to register any listener.

As soon as other Portlets are affected by any Ajax request, per default a rendering
(partial) on the client side could happens automatically.

Regards,
Andy


------ Originalnachricht ------
Von: "Martin Scott Nicklous" 
< >
An: 

Gesendet: 04.02.2014 17:19:14
Betreff: [jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model
Hi Andy,

I agree that other affected portlets need to be notified of changes.

As a summary, there are two proposals under discussion.

Proposal 2b:

https://java.net/projects/portletspec3/downloads/download/WorkingDocs/Ajax/JSR362AjaxProposal-2b.pdf
https://java.net/projects/portletspec3/downloads/download/WorkingDocs/Ajax/JSR362AjaxSlides-2b.pdf
https://java.net/projects/portletspec3/downloads/download/WorkingDocs/Ajax/JSR362AjaxMockup-2b.zip

and

Alternate Proposal:

http://www.portletfaces.org/downloads/jsr-362/jsr-362-ajax-proposal-alternate.pdf

regards,
Scott





 wrote on 04.02.2014 15:29:50:

 From: 

 To: 
,
 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
 side
 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
programmed manually by using a Javascript event listener for Portlet B?

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

 Regards,
 Andy


 ------ Originalnachricht ------
 Von: "Martin Scott Nicklous" 
< >
 An: 

 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
 >the
>action in terms of semantics. When a portlet receives an event, it can
 >update
>its state information just as it can if an action request is executed.
 >
>The client side programming model presented by the alternative proposal
 >requires
>different processing depending on whether an action is carried out or
 >whether
 >the portlet state is changed through an event.
 >
>If the portlet executes an action, it submits a form through a partial
 >action
 >URL. That portlet receives a partial response containing markup or
 >other
 >data
 >to display.
 >
>However, if that same portlet reaches that same state through an event
 >rather
>than through an action, the portlet client (JavaScript) has to listen
 >for
 >an
>event and submit a separate resource request in order to retrieve the
 >data
 >for display.
 >
>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
 >a
 >resource on the server is to be created or updated. That means that
 >there
 >can
 >never be a browser or HTTP proxy cache hit for the POST request, and
 >that
 >the
>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
 >infrastructure.
 >
>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
 >the
 >partial action request is responsible for parsing a complicated XML
 >document,
>extracting the JavaScript code that will cause the necessary broadcast
 >event,
 >and then executing ("eval()") the JavaScript code to broadcast the
 >event.
 >
>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
 >portlet
>client JavaScript code could break the whole page, which I believe is
 >not
 >good.
 >
>Also, the proposal would require specifying the message format returned
 >to
 >the
 >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
 >will
 >contain the private & public parameters for portlet A, but not for
 >portlet
 >B
>and portlet C. But the private parameters for portlet A do not interest
 >portlet
>B. And I don't understand how portlets B and C are supposed to obtain
 >their
 >new
 >state without always contacting the server to check for a potential
 >update.
 >
 >My impression is that the alternate proposal, from the client-side
 >programming
 >model point of view, might be a good fit for a JSF portlet issuing a
 >partial
>action request, but it looks to me like a less than optimal fit for a
 >page
 >full of non-JSF portlets.
 >
 >regards,
 >Scott
 >
 >




[jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model

andy . bosch 02/05/2014

[jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model

Martin Scott Nicklous 02/05/2014

[jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model

andy . bosch 02/10/2014

[jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model

Martin Scott Nicklous 02/10/2014
 
 
Close
loading
Please Confirm
Close