Re: [wsrp] Markup with pbia and handleEvents

[Subbu Allamaraju <subbu@bea.com>]

Rich Thompson wrote:
> 
> This sentence was drafted as a clarification of behavior intended in v1.  
> 
> a. It only includes mode and windowState because these are the only two 
> components of the returned information where the Consumer manages 
> changes in value.

I agree.

> b. The statement is providing guidance to the Portlet developer about 
> what the Consumer will consider the markup fragment to represent. A 
> conformance statement in this area would be untestable. Instead, we are 
> saying the Consumer will consider the portlet to have provided a 
> particular type of markup fragment ... if the portlet actually supplied 
> something else, it is no different than an invocation of getMarkup 
> returning a fragment that ignores the supplied parameters.

I agree that it is not testable, but each party may be treating the 
markup as belonging to a different state. At the protocol level there is 
no harm, but at the consumer/user level there will be a mismatch. But I 
guess the consumer can live with it.

> 
> c. Why shouldn't the Consumer be allowed to cache the fragment as 
> representing a particular state of the portlet and then manage that 
> cache entry the same as it would any other? The fact that it is for a 
> windowState and mode other than is what is currently showing to the user 
> doesn't make it invalid.

It is natural for a well-behaving consumer to discard the cached 
fragment (for better user experience) if the consumer is unable to honor 
  a mode change. For instance, if a user is not allowed the edit mode of 
a portlet, and the producer returned markup in edit mode, the consumer 
may not want to show that markup. It will be useful to have some 
guidance on this point in the spec.

Subbu



> *Subbu Allamaraju <subbu@bea.com>*
> 
> 07/03/05 07:06 PM
> 
> 	
> To
> 	wsrp <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	[wsrp] Markup with pbia and handleEvents
> 
> 
> 	
> 
> 
> 
> 
> 
> Sec 6.4.1 has a new sentence that reads as follows
> 
> "Also, the markup should be generated presuming that any requested mode
> or windowState changes are honored".
> 
> I've a few of questions on this wording.
> 
> a. Why not include other things like navigationalState, and
> portletContext (implicit cloning) in this sentence?
> 
> b. To make interop work, why not make this a MUST? Without a strong
> conformance requirement, the markup and what the consumer thinks of
> portlet's state may be inconsistent. For instance, a Producer could
> return markup in wsrp:view mode while asking for a mode change to
> wsrp:edit. Assuming that the Consumer's honors the mode change, the
> Consumer may end up showing wsrp:view mode's content for wsrp:edit mode.
> 
> c.Following (b), if a Consumer is unable to honor state changes, I think
> that it MUST discard the markup returned by the Producer.
> 
> Comments?
> 
> 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
> 
>