This does not work for "certain" implementations. Implementations will
have to seriously think about changing the assumption that consumer is
always *the* aggregator to be able to support modern web development
techniques.
Subbu
Richard Jacob wrote:
> I think this doesn't work.
> - how would the state of the other portets be encoded in the imbedded
> portetl URLs?
> - how could the other portlets maintain their URLs (containing nav state)
> pointing to the "isolated" portlet?
>
> The proposal would break a lot of things rather than fixing some use cases.
> We have to keep in mind that there *is* an aggregator which maintains
> states, navigations, etc.
> So if you go for an isolated portlet (is it a portlet then at all ;-) ) you
> could use resource URLs for that.
>
> Mit freundlichen Gruessen / best regards,
>
> Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Team Lead & Technical Lead
> WSRP Standardization
> Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
> Email: mailto:
>
>
>
> Subbu Allamaraju
> <>
> To
> 01/25/06 07:55 PM OASIS WSRP TC
> <>
> cc
>
> Subject
> Re: [wsrp] XMLHttpRequest and WSRP
> 2.0 - where do we stand?
>
>
>
>
>
>
>
>
>
>
> I'll be happy to discuss this further within the TC, but I don't think
> the proposal to add a param is partial. There are some details to be
> clarified in the spec on the semantics and update any implicit
> assumptions about aggregation. I will look into this further this week,
> and post to the TC.
>
> I propose to discuss this during the next interfaces call.
>
> Subbu
>
> Rich Thompson wrote:
>> What would be gained by such a partial solution that the portlet
>> couldn't simply manage itself (perhaps with Producer assistance) by
>> using resource URLs and a queue of pending updates within a session?
>>
>> If the long-term solution is clear (i.e. just needs the details worked
>> out) and the partial solution brings a high value, then I could see
>> including the partial solution in v2. Otherwise I would favor leaving
>> the discussion to v3.
>>
>> Of course, another option would be to delay v2 until a relatively
>> complete solution is designed ...
>>
>> Rich
>>
>>
>> *Subbu Allamaraju <>*
>>
>> 01/25/06 12:09 PM
>>
>>
>> To
>> OASIS WSRP TC <>
>> cc
>>
>> Subject
>> Re: [wsrp] XMLHttpRequest and WSRP 2.0 - where do we stand?
>>
>>
>>
>>
>>
>>
>>
>>
>> Thanks for your comments.
>>
>> As some of you might have noticed, there is a LOT of interest in the web
>> developer community in leveraging Ajax-style technologies. The key issue
>> with WSRP (and also the Portlet API in the Java-land) is that the
>> protocol prevents use of Ajax-style technologies in portlets. A few
>> people in the community have tried using XMLHttpRequest with WSRP and
>> the Portlet API, but could not make much progress.
>>
>> Taking one step at a time, the first and the key issue is guaranteeing
>> that a given render/action/resource URL would cause a consumer-driven
>> invocation and rendering of a single portlet.
>>
>> Here is a proposal. A new URL parameter, let us call it
>> "wsrp-aggregate", with a value of "false", would let portlets create
>> URLs that are guaranteed to cause a single portlet invocation.
>>
>> For example, to create an interaction URL to post some data via
>> XMLHttpRequest, a portlet would create a URL with wsrp-aggregate=false.
>>
>> The consumer will then invoke the phases of the portlet's lifecycle
>> (pbia, he, and getMarkup). Depending on how the consumer implements
>> support for events, it would either process events for all portlets on
>> the page, or store the events for later processing, or simply discard
>> events targeted for other portlets. Note that the current event model
>> makes no assumptions about page aggregation.
>>
>> IMO, other problems (see comments below) related to supporting
>> Ajax-style interactions are implementation specific. The key issue for
>> WSRP is to support such interactions within the protocol. Given the
>> popularity and interest in using Ajax in web apps, we should consider
>> taking the first steps towards supporting such interactions in V2, and
>> continue further work in V3 based on implementation experience.
>>
>> Regards,
>> Subbu
>>
>>
>> Rich Thompson wrote:
>> >
>> > While I would agree that supporting portlets which use AJAX-style
>> > communications is an important use case, I think a full discussion of
>> > the issues will not happen quickly. Some of the issues I see are:
>> >
>> > 1. While data oriented communications are reasonably supported via
>> > resource URLs, interactions that impact portlet state cause problems,
>> > such as:
>> > - inability to clone the portlet if enduring state changes
>> > - inability to communicate an updated navState back to the Consumer
>> > (consider what happens if the page updates due to a user interaction
>> > with a non-AJAX enabled portlet)
>> > - inability to leverage the new shared state models
>>
>> Right, and that was my motivation for bringing up this topic. Some of
>> the problems like page refresh and back buttons are fundamental to Ajax
>> style of interactions. As you may be aware, W3C Web API WG is looking
>> into these.
>>
>> > 2. Portlet state cached in the browser. Key point here is that the
>> > browser becomes part of the overall processing done by the portlet.
> Any
>> > state held within the browser can easily be lost; consider, for
> example,
>> > the impacts of a page refresh
>>
>> Right. The consumer will have to be smart enough to manage state such
>> that it is not lost due to a simple page refresh. A hard problem for the
>> consumer to solve, but not impossible. Given the strong interest in Ajax
>> among web developers, consumers will have to start considering these
>> problems.
>>
>> > 3. Insufficient browser security model. This is already an issue with
>> > composed pages (i.e. malicious portlet can activate an action link
> from
>> > a different portlet) though the user would get a reasonable
> notification
>> > by the page refreshing. If such a malicious portlet could also
> suppress
>> > the notification to the user, this problem becomes severe.
>>
>> I don't know Ajax-style interactions open new security issues. I think
>> the security issues are more fundamental.
>>
>> > 4. Coordination impacts. In order to preserve the concept of the page
>> > reacting as a whole to user interactions, AJAX-style actions really
>> > should use the full 3-steps of the protocol with the modification that
>> > only the impacted portlets are rerendered. I think this drives the
> model
>> > toward Consumer-control over such partial updates rather than asking
> the
>> > sourcing portlet to update multiple places on the page.
>>
>> I agree. Consumers wanting to fully support such interactions will have
>> to find better ways to implement event coordination. Consumers can no
>> longer assume that all portlets participating in an event train are
>> being rendered in an aggregated page. Similar issues arise if a consumer
>> is implemented using iframes.
>>
>> > #4 makes me think this ought to leverage the Consumer resource model,
>> > which has been deferred to v3. If others agree, perhaps this can be
> the
>> > early focus in the v3 discussions with the new ExtensionDescription
>> > mechanism leveraged to apply whatever is defined back into v2.
>> >
>> > Rich
>> >
>> >
>> > *Subbu Allamaraju <>*
>> >
>> > 01/24/06 12:58 PM
>> >
>> >
>> > To
>> > OASIS WSRP TC <>
>> > cc
>> >
>> > Subject
>> > [wsrp] 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
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this mail list, you must leave the OASIS TC that
>> > generates this mail. You may a link to this group and all your TCs
>> in OASIS
>> > at:
>> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> >
>> >
>> > ---------------------------------------------------------------------
> To
>> > unsubscribe from this mail list, you must leave the OASIS TC that
>> > generates this mail. You may a link to this group and all your TCs in
>> > OASIS at:
>> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. You may a link to this group and all your TCs in
> OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> --------------------------------------------------------------------- To
>> unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. You may a link to this group and all your TCs in
>> OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
