RE: [wsrp] Portlets and Forms

["Andre Kramer" <andre.kramer@eu.citrix.com>]

I also see issues with punting this up to portlet developers just so
that the consumer can avoid work when it (or its environment) chooses to
use a bounding <form></form>. However, we could have a flag
"portletAssertsNoHTMLFormsUsed" that has a default value of false. This
should mean the indicator serializes to nothing on the wire when not
asserted, but adds a little extra protocol data when true, allowing the
consumer to optimize processing (allows trading network bandwidth for
processing).

We should possibly have done usesMethodGet in the same way
(assertNoMethodGETandYesIDoUseHTMLForms with default false). But not all
WSDL/SOAP stacks optimize out default values currently, so such an
approach may be unattractive well past 2.0.

I do see the problem, but can't see a solution less than a full parse of
the markup (or defining a complete new form like mechanism (xforms?) to
overcome the HTML/browser non-nesting limitation).

Regards,
Andre

-----Original Message-----
From: Michael Freedman [mailto:michael.freedman@oracle.com] 
Sent: 06 April 2005 16:47
To: wsrp
Subject: Re: [wsrp] Portlets and Forms

There are three scenarios I can think of where the portlet/producer 
provides an indication of whether a form tag exists or not:

   1. The page is manually marked by the developer -- I.e. there is paeg
      meta dta the developer sets to indicate this.  Yes, this might
      become stale over time -- but that is a broken portlet that would
      quickly be detected when included in a form.
   2.  Markup is entirely generated by a set of markup/view components,
      hence the component tree can be inspected to determine if a form
      exists. I.e. the portlet rendering is implemented using a system
      like JSF.
   3. The parsing [filter] is included in the producer [to distribute
      the load].  This filter merely looks for a <form> tag and sets the
      return value accordingly.

     -Mike-

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



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