I'm glad the comments were useful.
On #2; This should be a matter of how
one wraps the underlying XMLHttpRequest. There should be means by which
the exception generated at the lower layers simply flows up the call chain
such that the requirements are met. Some testing is definitely called for
...
On #5; I would not require promoting
the blocking semantics to the page though certain implementations may choose
to do that as a simple means of achieving the contract they have with underlying
component technologies.
Rich
P.S. Before sending this, I did some
testing. The following wrapper works, though it obviously doesn't implement
a function to process/strip the framework's portion of the response. Neither
Firefox nor IE threw an exception at the invalid access attempt, but if
they had, it would have passed up the call chain to the code invoking the
wrapper (to validate this, I tried setting readyState, a readonly variable,
in my onreadystatechange function and was able to properly catch the exception
in the code using the wrapper).
// Obviously I did not try to wrap all
the possible signature types ...
function _open(verb, url, async)
{this.req.open(verb, url, async);}
function _send(stream)
{
var req = this.req; //
bring this into scope so it will be available later
var wrapper = this; //
bring this into scope so it will be available later
req.onreadystatechange
= function()
{
wrapper.readyState
= req.readyState;
if (wrapper.readystate>=3)
{ // process response,
stripping framework parts
}
wrapper.onreadystatechange();
}
req.send(stream);
}
function XMLHttpWrapper()
{
this.req = new XMLHttpRequest();
this.readyState = 0;
// will be set by the onreadystatechange handler
this.onreadystatechange
= 0; // will be set by the onreadystatechange handler
this.responseText = "";
// will be set by the onreadystatechange handler
// and so on ...
this.open = _open;
this.send = _send;
}
Subbu Allamaraju <>
10/03/2006 12:44 PM
To
Rich Thompson/Watson/IBM@IBMUS
cc
OASIS WSRP TC <>
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 <>*
>
> 09/21/2006 12:03 PM
>
>
> To
> OASIS
WSRP TC <>
> 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.
