OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Portlets and Forms

In looking to stengthen my argument we extend the request meta data with information about whether the page a portlet is being aggregated in has an enclosing form and whether the response contains a form I tracked done what Microsoft was doing to support WSRP via a WebPart in ASP.Net.  JSF like ASP.Net use single page form models. 

This information comes from Microsoft's WSRP Web Part Implementation Summary document included with the publically available web part implementation/source.

The following changes are made to the markup in Web Part’s MassageMarkup() method:

  1. All names of HTML input controls such as <input type=”text” name=…>, <input type=”radio” name=…>, <select …name=…>, <input type=”submit”>, etc.
    are modified to contain a prefix derived from WebPart UniqueID property to reflect its position on resulting SPS web page. This is especially important if two WSRP Consumer Web Part instances are added to SPS site and Web Part event handling code tries to find out which Web Part instance caused the event to occur.

  2. A client-side script invoked upon embedded form submission is added to <input type=”submit”> controls to add a new value to POST-able parameters. This value contains WebPart.UniqueID;

  3. Producer markup might contain a <form> HTML construct. However, since SPS page already has one and nested forms aren’t supported in IE, this additional form tag needs to be parsed out from markup. This procedure is also carried out in this method.

  4. JavaScript functions’ names are also assigned a prefix derived from Web Part UniqueID.
Its interesting to note that such an implementation doesn't seem to account for the following "edge" cases:
  1. What do we do with Javascrlpt [form] event handlers registered in the form tag?
  2. What do we do if enctype isn't  "application/x-www-form-urlencoded" e.g. the portlet has a file upload form?
  3. What do we do if the portlet sets/uses the accept-charset tag?
  4. How do we recognize/deal with [unencoded -- i.e. no wsrp_rewrite token] field references in Javascript? 
The point here is that tokenizing the form so the consumer can effectively rewrite seems cumbersome and clumsy.  Rather I think the original model I proposed whereby information can be communicated between the consumer and producer  will  be a better solution.  Specifically, I am hoping that solutions could use such communciation to drive a producer side filter to do the types of parsing suggested above for those portlets that don't adjust to a page with an enclosing form [and thereby avoiding doing this comuptation in the consumer]-- and hopefully [overtime] many producers will decide to adjust if/when they detect they are running in an enclosing form.

In addition, at a minumim we should start requiring that all form fields be namespaced.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]