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