[jsr362-experts:] Re: [jsr362-observers:] New version of Ajax proposal in slide form
- From: Martin Scott Nicklous <
- Subject: [jsr362-experts:] Re: [jsr362-observers:] New version of Ajax proposal in slide form
- Date: Tue, 22 Apr 2014 17:21:57 +0200
hmmm ... need to think about that a bit.
I see your point about the events, but so far I've been thinking of the
partial action as being more of a resource request with extended semantics
for action handling than a new type of action / render sequence.
In the back of my mind I was thinking that the getPageState() method (or
whatever we decide to call it) on the PartialActionResponse could cause the
portlet container to drive event processing to completion, although I
didn't really explicitly mention that or put it up for discussion. Although
now, when revisiting the idea, I can see that it might be difficult to do
through WSRP. I probably didn't think that through well enough.
If at all possible, I think it would be better to avoid completely new
phases like adding a third type of rendering, since both partial action &
partial render would need to be reflected in the WSRP spec as well as
implemented by the container.
How would partial action / partial render really differ from action /
render for a specific portlet (in general)?
How would partial action / partial render really differ from partial
action / serveResource?
How would partial action / partial render really differ from Ajax action /
serveResource (which according to the proposal we would continue to support
for native portlets)?
Another alternative might be to restrict the partial action to only
changing render parameters, or even to only changing private render
Anyway, there is still work to do ... :-)
Mit freundlichen Grüßen, / Kind regards,
WebSphere Portal Standardization Lead & Technology Consultant
Specification Lead, JSR 362 Portlet Specification 3.0
IBM Software Group, IBM Collaboration Solutions
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
wrote on 22.04.2014 15:41:13:
> From: Neil Griffin
> Date: 22.04.2014 15:42
> Subject: [jsr362-experts:] Re: [jsr362-observers:] New version of
> Ajax proposal in slide form
> Hi Scott (and friends of portlets!),
> As I mentioned during last week's call, I am delighted to see the
> proposed PartialActionRequest and PartialActionResponse interfaces.
> One assumption I have is that there would be a new method added to
> GenericPortlet to process partial actions:
> If that assumption is correct, then I think we would need a
> corresponding method to process the partial render:
> The reason is because rendering cannot take place until all of the
> events have fired. For example, Portlet A initiates the action and
> sends an event to Portlet B, and then Portlet B sends an event back
> to Portlet A that affects the rendered markup of Portlet A.
> So... that would be a total of 4 new interfaces:
> PartialActionRequest, PartialActionResponse, PartialRenderRequest,
> and PartialRenderResponse.
> Best Regards,
> On Apr 17, 2014, at 3:46 PM, Martin Scott Nicklous
> > wrote:
> Hello Friends of Portlets,
> I reworked the Ajax Proposal 2e slides to include the partial action
> request idea (to the extent that time allowed this week). See:
> * I haven't yet added namespacing to the methods, didn't get to it.
> However, I would like to point out that there will actually only be one
> method in the global namespace anyway, namely portlet.register(). The
> register method will return a Portlet-Client-specific object containing
> rest of the methods along with other information. See the "PortletInit"
> object description on page 13.
> * I'm not yet convinced of the necessity or advantages of an
> interface, since each of the portlets will receive portlet-specific data
> the "event" payload, so I did not yet introduce it into the proposal.
> I don't see the need for more events than the single "onStateChange"
> event / callback already defined for delivery of portlet state
> If we were to move to an event-oriented API, I would prefer to orient
> towards the DOM Level 2 definition:
> addEventListener(type, listener)
> because it allows specification of the event type that the listener wants
> to "hear". I think that would improve usability for developers.
> * I did not include any form of "actionParameters event" functionality,
> because I don't believe it should be needed. When the portlet render
> changes (due to user interaction or when the JSF Portlet Bridge code
> new content for a JSF portlet), the Portlet Client (or bridge.js code
> acting on behalf of a JSF portlet) should use the setPortletState()
> function to set any necessary private render parameters for the portlet.
> Those parameters will automatically be included in the URL by the portlet
> hub when an action() is performed or when an action or resource URL is
> created, since the Portlet Hub manages the page state. If I'm missing
> something here, please let me know.
> * I did not add any form of "dispatchActionRequestCallback" functionality
> that is replaced by the partial action request stuff.
> * I did not add any form of events for resource handling, since in this
> proposal obtaining resource URLs and performing the corresponding Ajax
> requests is completely under control of the individual portlet clients.
> Note that Germany has a long weekend over Easter. Both tomorrow (Friday)
> and Monday are public holidays, so I may be somewhat slow in response if
> you comment / write me.
> The meeting on Tuesday 22 April will take place as scheduled. I'm looking
> forward to it - we have a lot to discuss!
> Mit freundlichen Grüßen, / Kind regards,
> Scott Nicklous
> WebSphere Portal Standardization Lead & Technology Consultant
> Specification Lead, JSR 362 Portlet Specification 3.0
> IBM Software Group, IBM Collaboration Solutions
> IBM Deutschland Research & Development GmbH / Vorsitzender des
> Aufsichtsrats: Martina Koederitz / Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
> HRB 243294