Re: [wsrp] Portlets and Forms

[Subbu Allamaraju <subbu@bea.com>]

Mike,

Do you have any example, perhaps a sample faces file, that best 
illustrates the problem?

Thanks

Subbu

Michael Freedman wrote:
> 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
>