Portlets and Forms

[Michael Freedman <michael.freedman@oracle.com>]

When we developed WSRP 1.0 we assumed that portlets would be used 
primarily in Tables and/or iFrames.  Though I don't recall any specific 
discussion on the issues of embedding Portlets in an HTML form, the HTML 
<Form> tag is not a disallowed portlet tag.  Because HTML prohibits 
embedded <Form> tags in a document this restricts consumer pages from 
including portlets in [its] forms.  Unfortunately, JSF [aka Java Server 
Faces], a recent view technology [standard], by and large relies on the 
premise that multi-form based pages will only actually contain a single 
[page] form. One of the arguments made for this is it gives JSF the 
ability to retain unsubmitted form data that has been entered in the 
non-targeted forms.  JSF components are built based on this assumption 
-- i.e. JSF components are form agnostic; those that need to be embedded 
in a form merely assume they are so and rely on the page/developer to 
have properly wrapped the component/page in a form.  This includes 
sophisticated layout components that use forms [pull down menus, etc] to 
present UI for managing actions within the layout.  Because we allow 
portlets to generate forms they are incompatible with such components 
and hence can't be used in/with many JSF pages.  A simple example is a 
JSF component that renders/manages the chrome [titlebar/frame] for a 
child.  This component is used to wrap each visual group/entity with a 
common frame look/interaction model.  If this component uses any form 
field components in its UI [common because of the premise above] a 
portlet can not be embedded within it.

Basically, what I am saying is that there are issues/incompatibilities 
between JSF and our portlet model that complicates/restricts portlet use 
in this view technology.  Though hopefully the JSF standards body will 
consider these issues and suggest modifications to their standards its 
unlikely to happen soon.  JSF 1.2 is in the process of being wrapped up 
and this issue is too big to try and slip in.  JSF 2.0, the next 
potential update, is a long way off.  Instead, I ask us to consider 
making minor accomodations in WSRP 2.0 so that portlets that are aware 
of these issues can detect the environment they are running in and act 
accordingly.  What I suggest is the following:

   1. add an optional boolean field to MarkupRequest called
      embeddedInForm.  true indicates this portlet's markup is being
      aggregated into markup that contains an enclosing form.  Its
      absence provides no information, producers can assume this is
      equivalent to false.
   2. add an optional boolean field in MarkupResponse called
      containsForm[Tag].  true indicates this portlet's markup contains
      a form [tag].  false means the markup does not. absence provides
      no information, the markup may or may not contain a form tag.

By providing these two fields:

    * a portlet can be implemented to adjust to whether or not its
      already embedded in a form
    * a consumer can optimize [by avoiding] post processing of the
      portlet markup to adapt it to a single form environment.

   -Mike-