OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Ajax proposal uploaded



I had a chance (i.e. time in a waiting room) to go through this at a finer granularity. Here are my comments:

1. Each of the examples should use a try clause such that they get an XMLHttpRequest interface regardless of whether XMLPortletRequest is supported or not. (i.e. are better examples of relevant js code for portlet developers).

2. There are a number of comments about keeping this close but not quite semantically equivalent to the XMLHttpRequest definition underway at w3c. Other than the actually response being filtered to remove items targeted at the framework, exactly what deviations are expected? What is the rationale behind each of them?

3. A relatively minor point, but "ID" is too generic. I would suggest "requestID".

4. In section 2.2 (and elsewhere) you explicitly describe updating a fragment of the portlet's markup. While this could generically mean the view defining markup, some data fragments or some controller scripts, it would be good to be explicit somewhere early in the writeup that "portlet markup" includes any/all of these.

5. In section 2.3 you explicitly require the framework to block further input in the browser. Since this completely negates the value/reason for using asynchronous communications, why is it being required? I understand there may be server-side technologies where the component technology requires such single threading (for example, I think JSR 168 portlets would require this), however, I don't see a reason this is projected out to the entire page nor why it would apply when the component technology doesn't require it.

6. I would want to discuss further the names we apply to these interfaces as I think including the word "Portlet" in it makes it too specific. This might fall out naturally of a discussion about the broader area of component artifacts interacting with framework artifacts, but I would assert that a term which is more UA oriented would be better.


Rich



Subbu Allamaraju <subbu@bea.com>

09/21/2006 12:03 PM

To
OASIS WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject
[wsrp] Ajax proposal uploaded





I upload a JSR286-version of the Ajax proposal this morning. It is
located at

http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/20397/xpr-wd-03.html

For some reason, this upload did not generate an email to the group.

This document proposes two script interfaces XMLPortletPortlet and
XHLHttpRequestFactory.

There are a few examples of these interfaces at
http://wsrp.bea.com:7001/ajax.

Subbu
>>Register now for BEA World 2006 --- See http://www.bea.com/beaworld<<
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]