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


Thanks for the detailed comments. Please see my response below. I will 
upload the document with your comments/response.

Subbu

> 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).

I agree.

> 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?

Attributes like responseXML, responseText, status, and statusText are 
the problematic ones. Per the latest draft of XMLHttpRequest, 
implementations are required to throw an INVALID_STATE_ERR when these 
attributes are accessed when readyState is less than 3. It is possible 
to support this requirement when the proposed interface is implemented 
natively in a browser.

In our case, the most likely implementation of XMLPortletRequest would 
be based on JavaScript, in which case, it is not possible to raise 
INVALID_STATE_ERR when this attribute is accessed. The implementation 
will just have to return initial values for these fields. Alternatively, 
we could say that portlets MUST NOT access these attributes when the 
value of readyState is other than 3 or 4.

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

I agree.

> 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.

I agree.

> 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.

The key issue is that portlet developers don't care about this. As far 
as portlets concerned, they would like to update a fragment without full 
page/portlet rendering. When the URL supplied to XMLPortletRequest is a 
blocking action URL, don't we need to somehow enforce the blocking 
semantics? Alternatively, we can omit saying this, and let the current 
semantics specified for the consumer continue to apply - which I presume 
would be the default.

> 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.
> 

_______________________________________________________________________
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]