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