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:
- 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.
- 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;
- 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.
- 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:
- What do we do with Javascrlpt [form] event handlers registered in
the form tag?
- What do we do if enctype isn't
"application/x-www-form-urlencoded" e.g. the portlet has a file upload
form?
- What do we do if the portlet sets/uses the accept-charset tag?
- 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.
-Mike-
|