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: Mon, 10 Feb 2014 11:59:39 +0100

Hi Andy,

The problem also occurs when only certain fields within a portlet are to be
replaced rather than the entire portlet.

Also, there are folks who add the Javascript for a portlet in the doHeaders
method, so that it lands in the <head> section rather than in the body of
the portlet.

so ... hmmm ... I agree that there are cases where it could work if you
assume that the entire portlet is replaced and that the portlet JavaScript
is included in the portlet body and that it is coded in a certain  manner.
And even then you might have issues with getting the portlet JavaScript to
initialize properly. For example, I don't believe that window.onload()
fires when JavaScript is added through a DOM update.

However, replacing the entire portlet might be something we would do to add
support for JSR 286 portlets, but I wouldn't consider it a main use case
for JSR 362 portlets. For JSR 362 we want to allow a stateful Ajax request
(meaning that an action request is executed through Ajax) and allow all
affected portlets to update themselves in an Ajax manner, meaning that they
would only update the necessary portions of their UI rather than the entire
portlet.

regards,
Scott



 wrote on 10.02.2014 11:08:54:

> From: 
> 
> To: 
>  ,
> Date: 10.02.14 11:09
> Subject: [jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) -
> Client Programming Model
>
> Hi Scott,
>
> I agree, that an automatic re-rendering could become very
> complex and difficult, if any JavaScript is involved, which is not
> under the control of the Portlet API.
>
> But: When we think of Portlets as self-containing page fragments,
> all JavaScript (with all listeners etc) is inside the Portlet window.
> A re-rendering of the Portlet window should not make any problems,
> as all listeners would be re-attached.
>
> The problem you described occurs, if there is any JavaScript _outside_
> the Portlet window. Then a partial re-rendering could cause
> serious problems.
>
> Doing an automatic re-rendering for the first case I described seems not
> to be very difficult. It is similar to an Observer pattern: If something
> has
> changed on the server side (Portlet events, state change, Render
> parameter, ...),
> the Portlet will receive an event to re-render itself).
>
> So I think it depends on the specific Portal page, whether an automatic
> re-rendering can be performed or whether the user has to do it manually.
> Perhaps we could introduce such a behaviour and let the user decide
> whether
> to switch it on or off?
>
> Regards,
> Andy
>
>
> ------ Originalnachricht ------
> Von: "Martin Scott Nicklous" 
> < >
> An: 
> 
> Gesendet: 05.02.2014 13:42:59
> Betreff: [jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) -
> Client Programming Model
> >Hi Andy,
> >
> >We talked about an automatic re-rendering approach some time ago. I
> >think
> >an automatic re-rendering of all affected portlets would be really
> >difficult to do properly.
> >
> >Any central component on the client that would not in general have any
> >information about how the individual portlets work, or about what the
> >individual DOM nodes are actually used for. In particular, you don't
> >know
> >what JavaScript routines the individual portlets have running or how
> >they
> >work. Some JavaScript routines might place listeners on the nodes that
> >would need to be moved to new nodes if certain nodes are replaced.
> >Other
> >JavaScript might internally hold arrays or maps pointing to DOM nodes.
> >If
> >the node is replaced or deleted automatically, the JavaScript would
> >have to
> >be written so that such cases are handled. That would place big
> >restrictions on how JavaScript for portlets has to be written.
> >
> >Also, a portlet on the page might require several updates, which could
> >be
> >deletions, additions, or replacements. So the code on the server that
> >generates the updates and the code on the client that parses and
> >applies
> >the updates to the DOM would have to be written to handle any number of
> >various types of updates in any number of portlets. In addition, you
> >would
> >have to define some sort of rules on the order of "any replaceable node
> >must have an id attribute" for markup generation, and the portlet
> >developers would have to follow the rules.
> >
> >And sometimes the portlet JavaScript code might just want data that
> >doesn't
> >directly land in the DOM. The portlet JavaScript code would use the
> >data to
> >generate the portlet UI indirectly - think of a portlet that
> >dynamically
> >creates some sort of chart. An update of this type would have to be
> >handled
> >as well.
> >
> >Any general solution would have to be very complex on the server as
> >well as
> >on the client - if it could be made to work at all.
> >
> >So I think it would be better to have each portlet do its own update.
> >That
> >way, complexity of the Ajax support code on the server and on the
> >client
> >can be minimized and the responsibility for the portlet UI stays solely
> >with the portlet (where it should be imho).
> >
> >regards,
> >Scott
> >
> >
> > wrote on 05.02.2014 11:34:01:
> >
> >>  From: 
> >> 
> >>  To: 
> >>  ,
> >>  Date: 05.02.14 11:34
> >>  Subject: [jsr362-experts:] Re: JSR 362 Ajax Proposal (alternate) -
> >>  Client Programming Model
> >>
> >>  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