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 <>*
>
> 06/01/05 06:26 PM
>
>
> To
> wsrp <>
> 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
