[jsr362-observers:] [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets and JSF
- From: Martin Scott Nicklous <
- 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>
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
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.
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?
(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
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.
wrote on 30.10.2013 16:39:32:
> From: Neil Griffin
> Date: 30.10.13 16:39
> Subject: [jsr362-experts:] Re: Some general thoughts on Ajax, Portlets
> 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
> I would like to offer an idea that would be compatible with most
> the action-event-render lifecycle....
> 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
> uses for the Ajax postback.
> Now, along that same line of thought, jQuery developers will want to
> perform Ajax via jQuery.ajax()
> ... YUI3 developers will want to perform Ajax via Y.io()
> ... and DOJO developers will want to perform Ajax via 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
> 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
> would also not require any changes to the portlet programming model,
> other than a new method called MimeResponse.createPartialActionURL()