Re: [wsrp] Portlets and Forms

[Rich Thompson <richt2@us.ibm.com>]

This sounds like a good use case for
when Portlets and Consumers are willing to dynamically adjust whether or
not they include a <form> tag in their portion of the markup.  Basically:

1. Portlet is willing to dynamically
determine whether or not to include a form tag. Such a Portlet is usable
both stand-alone and embedded within someone else's form (presumably the
processing of the enclosing form would parcel out the embedded inputs properly).
This type of Portlet needs to know whether or not it is being embedded
in someone else's form ... this sounds like a good use for a well-known
public parameter.

2. The Consumer is willing to dynamically
determine whether or not to generate a <form> tag (or strip Portlet
<form> tags) when embedding the Portlet's markup into the page. Such
a Consumer needs to know whether or not a Portlet has form tags within
its markup. The two possibilities for gaining such knowledge are having
the Portlet explicitly say whether or not a <form> tag was included
(Mike's suggestion) and parsing the markup. While we certainly want to
avoid situations where parsing a Portlet's markup is required, I would
question both whether and how a Portlet would accurately state that a particular
markup fragment contained a <form> tag. I can imagine how a JSP compiler
could do this for a Portlet using JSPs to generate its markup, but they
don't today and there certainly are a lot of other ways markup is generated.

Rich

Michael Freedman <michael.freedman@oracle.com>

04/05/05 07:42 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	[wsrp] Portlets and Forms

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-


---------------------------------------------------------------------
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