Re: [wsrp] Portlets and Forms

[Subbu Allamaraju <subbu@bea.com>]

On your second point, I think it may be hard for portlets to advertise 
if they are using form tags or not, considering that some portlets are 
quite large (with lots of pages). The chance of dev/user error is more.

Subbu


Rich Thompson wrote:
> 
> 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
> 
>