Skip to main content

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

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-experts:] JSR 362 Ajax Proposal (alternate) - Client Programming Model
  • Date: Mon, 3 Feb 2014 09:40:46 +0100



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