Skip to main content

[jsr362-experts:] JSR 362 Ajax Proposal (alternate) - General Comments, User Stories (read first!)

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-experts:] JSR 362 Ajax Proposal (alternate) - General Comments, User Stories (read first!)
  • Date: Mon, 3 Feb 2014 09:32:40 +0100


Hi Neil,

Thanks for submitting the JSR 362 Ajax Proposal (alternate). This is a big
help
in furthering the discussion about Ajax support for portlets.

Comparing this proposal with the JSF Ajax support, I can see the pedigree,
and
can understand how this proposal would fit in well with a portal that uses
JSF to a great extent. However, there are many portlets that do not use
JSF, and
there are many portal installations that for one reason or another do not
want
to use JSF. Therefore it is very important that any solution works well
with
non-JSF portlets.

It is also important that any solution we standardize in JSR 362 does not
take
away functionality already available through JSR 286. It must add
capabilities
and flexibility and may not detract from existing functionality. On this
point,
I believe that the alternate proposal optimizes support for JSF portlets,
but
reduces flexibility and capabilities for portlets in general and results in
a
less clear programming model as compared to the Ajax Proposal 2b that we
have
previously discussed.

To illustrate these points, I have quite a few comments, and I am going to
organize them in separate posts according to topic. I'm going to send off
all
of these posts pretty much at once, but I want you to know that I was not
saving
them up in order to drop them on you. I wrote these posts yesterday at home
while my wife was at her band practice, and I wanted to clearly separate by
topic, so I sort of wrote them in parallel. It ended up being more than I
had
anticipated.

User Stories:
=============

Comments to Story 1) "As a portal user, I want different applications on a
web
page to be able  to visually coordinate without a full page refresh."

I believe this point needs to be differentiated. There are two mechanisms
by which
portlets can coordinate.

  a) By setting public render parameters. This type of coordination does
not require
  on update to server state, so it can be carried out through use of the
HTTP GET
  method.
  b) Through use of events. Events are initiated through an action request
to
  one portlet. The Action request is submitted through an HTTP POST method,
since
  it has the potential of changing the state of the portal.

In addition to this comment, I have new user stories, many of which can
already be served through JSR 286 functionality, that I believe need to be
taken
into account.

In light of this, I propose the following alternate formulations of the
user
stories:

1) As a portal user, I want to view (GET) different data within a portlet
without
causing a full page refresh.
2) As a portal user, I want to view (GET) different data within a group of
coordinating portlets without causing a full page refresh.
3) As a portal user, I want to change (POST) data within a portlet without
causing a full page refresh.
4) As a portal user, I want to change (POST) data within a portlet and have
that portlet and all coordinating portlets on the page update without
causing
a full page refresh.
5) As a portal user, I want to get help or change settings in a portlet
without
causing a full page refresh.
6) As a portal user, I want to change the portlet state without causing a
full
page refresh.
7) As a portal user, I want to use the back / forward buttons to move back
and
forth through updates on the portal page without causing a full page
refresh.
8) As a portal user, I want to bookmark specific views of my portal page,
even if
those views were reached through Ajax requests.
9) As a portal user, I want to be able to jump back to previously viewed
data
quickly.
10) As a portal user, I want to be protected from hackers. Nobody should be
able
to send me a link to a portal page that would cause harm (debit my bank
account,
for example).
11) As a portal user, I want to be protected from mistakes (double
submission
of an action debiting my bank account, for example).

There are certainly more possible stories, but these came to mind quickly.

Story #9 implies optimal use of the browser cache and of the HTTP caching
proxy
infrastructure for all content possible (markup fragments, images, etc.) in
order
to insure optimal response times.

Stories #10 and #11 can be achieved through specific constructs within the
acion URL.

I'll touch upon the implications of these user stories in later posts.

General Comments:
=================

1) My position on JSF is that the Ajax solution we choose should make it
possible
to support JSF very well.

However, I would not be in favor of any requirements that would call for us
to
use the JSR 329 Portlet Bridge unchanged or with as few changes as
possible. It may well be that the bridge needs to undergo considerable
changes
to work  well with the portlet hub on the client.

2) We need to assure a clear, clean programming model on the client as well
as
on the server.

3) We need to minimize the programming work necessary to use the APIs we
define.

4) We should assure that portlets remain as independent from one another as
possible. We should reduce the chance to the greatest degree possible that
a
programming error or omission by one portlet would break other portlets on
the
same page.

5) I disagree with the idea that a JavaScript programmer will want to
receive
markup as the direct result of an Ajax request.

I believe that it is more important to insure a clean, consistent
programming
model than to transmit markup as quickly as possible.

6) In terms of performance, I believe that it is more important to assure
that
the markup or other data for display can be made cacheable by the browser
or
by an HTTP proxy than it is to reduce the number of Ajax requests by 1 or a
small number.

7) Some portal implementations store much of the page state information in
the session, while others, such as WebSphere Portal, store the page state
in
the URL. Any Ajax solution we standardize must support both types of portal
well.

8) An important requirement from my view would be that the portal always
has
the right to do a redirect to the same page causing a full page refresh as
a
response to an action request. After the redirect, the portlets must render
properly according to their render parameters. This is a JSR 286
functionality
that I believe cannot be dropped.

regards,
Scott



[jsr362-experts:] JSR 362 Ajax Proposal (alternate) - General Comments, User Stories (read first!)

Martin Scott Nicklous 02/03/2014
 
 
Close
loading
Please Confirm
Close