Skip to main content

[jsr362-observers:] [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-observers:] [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF
  • Date: Thu, 31 Oct 2013 09:58:15 +0100
  • List-id: <jsr362-experts.portletspec3.java.net>

Hi Neil,

I understand your idea to provide a PartialActionURL that would only render
the single portlet, but I think there are additional things that need to be
worked out.

1) It might be that the active portlet (the one initiating the action)
would only need a partial update, which would make it more appropriate for
that portlet to obtain its data from serve resource rather than from the
render method. Naturally it would be possible to handle that as a special
case in during rendering, but that would potentially introduce a certain
degree of ugliness into the portlet Java code.

2) We need well-defined events and reliable actors on the client side to
fire and handle the update events. Many (pretty modern) browsers support a
DOMObserver that watches for updates to a specified branch in the DOM tree,
which one could use to determine that something has changed. But then what
would you do when you find out something has changed? I don't think you
would want each portlet to just blindly do a server round trip to discover
if there is new data available, I think we need a mechanism that
specifically identifies the portlets that need to update themselves. I
don't think it would be good to rely on (or place the burden on) the
portlet programmers to insert script to fire the appropriate event.

3) It has to work both ways: A JSF portlet that changes public render
parameters to fires events needs to be able to cause other non-JSF portlets
to (partially) update themselves and active non-JSF portlets that use
portlet coordination needs to be able to cause a JSF portlet to update
itself, either partially or entirely.

Would it be possible for the JSF bridge to inject JavaScript into the
portlet markup to deal with the portlet-specific updates & communication on
the client side?

Last night a scenario occurred to me that I would like to understand
better. It's a general JSF scenario, independent of portlets. Can you
handle the following with JSF?

Scenario: You have a JSF page that embeds a non-JSF javaScript component
(call it a widget) on the page. This might be due to legacy reasons or
because the widget was developed by a different company or team. Both the
widget and the JSF portion of the page carry out Ajax communication with
the server, and they both have a form that can be submitted. You want the
page as a whole to work in an Ajax manner.

a) When the widget form is submitted, it might change something on the
server that would necessitate at least a partial update to the JSF portion
of the page. Is there a way for a general JavaScript routine to inform JSF
that it should update its markup? ... I haven't found any such mechanism in
my reading, but I may have overlooked something.

b) When the JSF form is submitted, it might change something that would
necessitate a partial update of the widget. Is there a way for JSF to
inform the widget that it needs to update its markup? This way around is
easier for me to imagine a solution - you might be able to use the JSF
onevent callbacks, or you might be able create a solution by intercepting
the jsf.ajax.request() method.

regards,
Scott

Neil Griffin 
< >
 wrote on 30.10.2013 16:39:32:

> From: Neil Griffin 
> < >
> To: 
>  ,
> Date: 30.10.13 16:39
> Subject: [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets
and JSF
>
> Hi Scott,
>
> (I was just about to send this message on the other thread you
> posted about the minutes, but I think the AjaxActionURL idea you
> mention the email you sent below might fit well with this)
>
> In the minutes, you wrote:
> Scott's comment, not discussed directly in call: If I understood the
> gist of the above
> arguments correctly, the suggestion would be that we introduce
> capability that would
> allow stateful Ajax updates without running through the portlet
> action-event-render
> lifecycle.)
>
> I would like to offer an idea that would be compatible with most
> JavaScript frameworks and also provide the ability to run through
> the action-event-render lifecycle....
>
> But first, here is (what I understand to be) the typical JavaScript
> framework use-case:
>
> Frameworks like JSF provide the jsf.js library and corresponding
> f:ajax tag. Component suites like PrimeFaces bypass this mechanism
> by providing the primefaces.js library and corresponding p:ajax tag.
> So in both cases, either jsf.js or primefaces.js expect to be in
> full control of issuing the XmlHttpRequest. The way JSF portlet
> bridges integrate with this is by simply providing a
> javax.portlet.ResourceURL that the underlying JavaScript library
> uses for the Ajax postback.
>
> Now, along that same line of thought, jQuery developers will want to
> perform Ajax via jQuery.ajax()
> http://api.jquery.com/jQuery.ajax/
>
> ... YUI3 developers will want to perform Ajax via Y.io()
> http://yuilibrary.com/yui/docs/io/
>
> ... and DOJO developers will want to perform Ajax via dojo/request/xhr:
> http://dojotoolkit.org/reference-guide/1.9/dojo/request/
> xhr.html#dojo-request-xhr
>
> My idea would be to introduce a new type of portlet URL called
> javax.portlet.PartialActionURL that would cause the portlet
> container to do the following:
>
> 1. Execute the ACTION_PHASE for the portlet targeted by the
PartialActionURL
> 2. Execute the EVENT_PHASE
> 3. Rather than return HTTP Status Code 301 (Redirect to a
> RenderURL), execute the RENDER_PHASE (BUT ONLY FOR THE PORTLET
> TARGETED BY THE PartialActionURL). The portlet container would not
> return a complete HTML document with all the portlets, but rather
> only the the fragment of markup for the targeted portlet.
> 4. During the RENDER_PHASE, allow the portlet developer to render a
> <script>...</script> that would participate in client side event
> notifications. That way, interested portlets could listen to such
> events and subsequently invoke an existing javax.portlet.ResourceURL
> in order to update themselves. The developer would be free to use
> any type of client side eventing mechanism, but we could provide a
> default mechanism via portlet.js.
>
> I think that this approach could be integrated into JSF portlet
> bridges and also be leveraged by other JavaScript frameworks. It
> would also not require any changes to the portlet programming model,
> other than a new method called MimeResponse.createPartialActionURL()
>
> Neil



[jsr362-observers:] [jsr362-experts:] Some general thoughts on Ajax, Portlets and JSF

Martin Scott Nicklous 10/30/2013

[jsr362-observers:] [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF

Neil Griffin 10/30/2013

[jsr362-observers:] [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF

Martin Scott Nicklous 10/31/2013
 
 
Close
loading
Please Confirm
Close