[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XMLHttpRequest and WSRP 2.0 - where we stand?
I have been investigating various use cases that developers are trying to solve by using XMLHttpRequest in their applications, and how WSRP stacks up against those use cases. I do find some limitations in the protocol that make it hard to solve some use cases. I would like to find out what people think. Most of the use cases that rely on XMLHttpRequest can be grouped into two categories: a. Downloading data/markup: An example is auto-filling forms based on what the user entered previously. This is similar to google-suggest. b. Submitting data: An example is a user login. Upon login, the browser replaces the login form with another markup fragment. Netflix's movie rating is another example. The first use case is idempotent, and URLs to download data/markup can be created as resource URLs. Now that WSRP 2.0 provides the portlet's context while fetching resources, developers can let portlets return xml/markup. The second use case is typically non-idempotent. Portlets may want to change their state while processing data. In some cases, portlets may be affecting the state of other portlets either via spec-provided coordination mechanisms or some producer-managed sharing. But it turns out that implementing the second use case is very tricky. Let me jot down the key steps that a portlet might try: a. Create an action URL in the markup. b. Submit data to the this URL c. Update browser to use/render returned data/markup But these steps don't play well with WSRP. In most implementations, the generated action URL points to an aggregated page which causes a pbia, zero or more handleEvents, and one or more getMarkup calls. In the current use case, the portlet needs a URL that is guaranteed to cause a pbia for the targeted portlet, and return markup for the same portlet. That is, the consumer must not return an aggregated page for this to work. The difficulty is that the protocol does not provide a way to create such an interaction URL. The nature of the URL is completely up to implementations. Implementations cannot solve it either since portlets may be creating normal interaction URLs and these special portlet-only URLs in the same markup fragment and producers/consumers can't distinguish between these two. Currently, developers can work-around this use case only via resource URLs. But resource URLs don't permit state changes, and so limit the ability of portlets to handle the use case completely. I'm seeking comments from this group on how important these use cases are for your implementations, and have any thoughts on supporting these use cases. Regards, Subbu
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]