Portlet and Forms

My action items from last week were to summarize the portlet/form
issue/needs and enumerate the approaches we need to take.  As we
identified a number of mechanism last week that these approaches could
be expressed in, I was also asked to illustrate the approaches using
each mechanism.  This message contains all this information except for
the later.  While I continue to work on this information, a first step
is to review the curernt guidance we give in wsrp 1.0 on dealing with
forms and ask how we might recast this given our broader understanding
of consumer environment.  To get things started I have included a
discussion of this at the end of the message.

Summary:

As we have been discussing, WSRP 1.0 allows/assumes portlets are free
to generate markup that includes <form> tags.  Consumer view
technologies including ASP.Net and JSF define/use a single all
encompassing page form.  Unfortunately, html doesn't support nested
forms.  WSRP portlets [that generate forms], therefore, can't be
aggregated directly into such pages.  Current solutions [Microsoft WSRP
Webpart] relies on parsing the portlet's generated markup and rewriting
the content to conform with the aggregating page's requirements.  There
are, however, a number of edge cases that such parsing finds difficult
if not impossible to deal with.  These include:

  
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?

In addition there is the general performance question/concern in
requiring the consumer to parse the portlet's markup whether of not the
markup contains a form or not.  In addition, because of some of the
edge cases above solutions may have to rely on multi-pass parsing.

Approaches:

As I said above, our first approach should be to review what wsrp 1.0
says about dealing with forms and consider recasting this to better fit
with consumers that supply enclosing forms.  I suggest we add a new
section to 10.5.1 [HTML markup Fragment Rules] -- or as a
subsection of 10.5.1.2 [Other tags].  The new section says something
like this:

There are special considerations in using the <form> tag.  HTML
disallows nested <form> tags.  The consumer is allowed to nest
the portlet in a form.  Such consumers are responsible for transforming
portlet markup to avoid this limitation.  However, depending on the
complexity of the portlet's form, the consumer may not be able to
provide a complete transformation.  To ensure the portlet works
correctly across the widest variety of environments, the portlet SHOULD:

  
always namespace prefix all form field names [hidden or
otherwise].  See section 10.3 for namespace encoding techniques.

  
avoid using form level Javascript.  Instead use field level
Javascript.

  
avoid using/setting the form tag's accept-charset attribute.

In addition, the portlet dmeveloper should be aware that consuers
nesting portlets in a form may have a difficult time dealing with any
form whose enctype attribute differs from the enclosing form.  

We also need to rewrite section 10.3 on Namespace encoding as this
section discourages namespacing a field's name attribute. This section
may also need to clarify what the portlet should expect when it uses
wsrp_rewrite_ to namespace a token.  The section implies the consumer
replaces this marker with a namespaceID and doesn't strip this ID when
passing the submitted field onto the portlet in the subsequent
request.  Is this correct?  If so, how does the portlet remove this
prefix to identify its field?

Optionally, we can consider allowing portlets to rely on supplying the
form tag.  In this option, a portlet would write its form fields
according to the rules above but not enclose them in a form tag.  The
portlet would return in the response a requiresEnclosingForm boolean
indicating to the consumer it must wrap the markup in a form tag.  If
we want to get general here, we could expand this to also indicate the
encoding of the form so not just form parameters would be expressed. 
The idea here is to solve this problem by not having the portlet code
as if they are being inserted into an enclosing form.  That way its
both easy for JSF/ASP.Net form-based consumers as well as other
non-form based consumers to get the correct behavior.

    -Mike-