[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]