[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Portlet and Forms
Rich, Do you mind sharing your review of these design decisions. I do have some fundamental questions on this issue, but have not had the chance to understand those. Regards, Subbu Rich Thompson wrote: > > After finishing shaking my head at the design decisions made in some > of these technologies, I agree that the suggested updates to the > various sections of the spec are appropriate. On the first, I would > favor a new section calling out the issues with the html form tag. > > On you optional suggestion of a requiresEnclosingForm flag. This > sounds like it would be better addressed by the Consumer Resources > feature that we have deferred to v3 and I would rather wait than have > an idiosyncratic solution for html forms. > > While you did not comment on it, would it be valuable to have form > usage information in MarkupContext (i.e. containsForms)? > > Rich > > > *Michael Freedman <michael.freedman@oracle.com>* > > 06/01/05 06:26 PM > > > To > wsrp <wsrp@lists.oasis-open.org> > cc > > Subject > [wsrp] Portlet and Forms > > > > > > > > > > My action items from last week were to summarize the portlet/form > issue/needs and enumerate the approaches we need to take. As we > identified a number of mechanism last week that these approaches could > be expressed in, I was also asked to illustrate the approaches using > each mechanism. This message contains all this information except for > the later. While I continue to work on this information, a first step > is to review the curernt guidance we give in wsrp 1.0 on dealing with > forms and ask how we might recast this given our broader understanding > of consumer environment. To get things started I have included a > discussion of this at the end of the message. > > Summary: > As we have been discussing, WSRP 1.0 allows/assumes portlets are free > to generate markup that includes <form> tags. Consumer view > technologies including ASP.Net and JSF define/use a single all > encompassing page form. Unfortunately, html doesn't support nested > forms. WSRP portlets [that generate forms], therefore, can't be > aggregated directly into such pages. Current solutions [Microsoft > WSRP Webpart] relies on parsing the portlet's generated markup and > rewriting the content to conform with the aggregating page's > requirements. There are, however, a number of edge cases that such > parsing finds difficult if not impossible to deal with. These include: > 1. What do we do with Javascrlpt [form] event handlers > registered in the form tag? > 2. What do we do if enctype isn't > "application/x-www-form-urlencoded" e.g. the portlet has a file > upload form? > 3. What do we do if the portlet sets/uses the accept-charset tag? > 4. How do we recognize/deal with [unencoded -- i.e. no > wsrp_rewrite token] field references in Javascript? > In addition there is the general performance question/concern in > requiring the consumer to parse the portlet's markup whether of not > the markup contains a form or not. In addition, because of some of > the edge cases above solutions may have to rely on multi-pass parsing. > > Approaches: > As I said above, our first approach should be to review what wsrp 1.0 > says about dealing with forms and consider recasting this to better > fit with consumers that supply enclosing forms. I suggest we add a > new section to 10.5.1 [HTML markup Fragment Rules] -- or as a > subsection of 10.5.1.2 [Other tags]. The new section says something > like this: > > There are special considerations in using the <form> tag. HTML > disallows nested <form> tags. The consumer is allowed to nest the > portlet in a form. Such consumers are responsible for transforming > portlet markup to avoid this limitation. However, depending on the > complexity of the portlet's form, the consumer may not be able to > provide a complete transformation. To ensure the portlet works > correctly across the widest variety of environments, the portlet SHOULD: > 1. always namespace prefix all form field names [hidden or > otherwise]. See section 10.3 for namespace encoding techniques. > 2. avoid using form level Javascript. Instead use field level > Javascript. > 3. avoid using/setting the form tag's accept-charset attribute. > In addition, the portlet dmeveloper should be aware that consuers > nesting portlets in a form may have a difficult time dealing with any > form whose enctype attribute differs from the enclosing form. > > We also need to rewrite section 10.3 on Namespace encoding as this > section discourages namespacing a field's name attribute. This section > may also need to clarify what the portlet should expect when it uses > wsrp_rewrite_ to namespace a token. The section implies the consumer > replaces this marker with a namespaceID and doesn't strip this ID when > passing the submitted field onto the portlet in the subsequent > request. Is this correct? If so, how does the portlet remove this > prefix to identify its field? > > Optionally, we can consider allowing portlets to rely on supplying the > form tag. In this option, a portlet would write its form fields > according to the rules above but not enclose them in a form tag. The > portlet would return in the response a requiresEnclosingForm boolean > indicating to the consumer it must wrap the markup in a form tag. If > we want to get general here, we could expand this to also indicate the > encoding of the form so not just form parameters would be expressed. > The idea here is to solve this problem by not having the portlet code > as if they are being inserted into an enclosing form. That way its > both easy for JSF/ASP.Net form-based consumers as well as other > non-form based consumers to get the correct behavior. > -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]