wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Portlet and Forms
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Wed, 8 Jun 2005 15:45:48 -0400
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]