OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]