Skip to main content

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

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) - Client Programming Model
  • Date: Tue, 4 Feb 2014 17:19:14 +0100

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:] JSR 362 Ajax Proposal (alternate) - Client Programming Model

Martin Scott Nicklous 02/03/2014

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

andy . bosch 02/04/2014

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

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