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: Thu, 9 Jun 2005 13:30:51 -0400
I agree that this is one of the values
of having the collective state of the page come back to the server on each
interaction. Once one makes that step of state management, one then has
to decide whether the state makes the roundtrip in a hidden form field
(ASP's choice), on the URL or in a cookie. My current understanding is
that JSF uses the last of these, which makes the requirement for wrapping
the page in a form less understandable ... though I'm sure there were reasons
for the design choice.
Anyway, this is an interesting tangent,
but the key issue is that the WSRP protocol needs to take into account
such design decisions of significant technologies, regardless of what we
think of those choices.
Rich
Michael Freedman <michael.freedman@oracle.com>
06/09/05 01:04 PM
|
To
| Rich Thompson/Watson/IBM@IBMUS
|
cc
| wsrp <wsrp@lists.oasis-open.org>
|
Subject
| Re: [wsrp] Portlet and Forms |
|
One rationale I have heard relates to maintaining the
collective state of all forms. I.e. a page containing 3 [logical]
forms that have been grouped into one allows a user to fill in form fields
across all 3 [logical] forms, submit in any given one and have the values/state
of the other [logical] forms not lost.
-Mike-
Rich Thompson wrote:
I certainly wouldn't go so far as describing what I have done as a review
of the various design decisions! I did consider deleting that comment before
hitting send, but I suspect the frustration it expresses is not unique
among us.
Areas that cause me to just shake my head:
HTML: Why isn't a nesting of forms supported? It would be very straight
forward to define a semantic for what this means (e.g. each form submits
all the data it encompasses, even if that data comes from a nested form)
and it would allow many advanced composition models to operate more smoothly.
As an aside, a previous tag language I worked with allowed the equivalent
and it introduced no difficulties I am aware of (other than the constant
issue that producing bad UIs is simple, regardless of how they are produced).
ASP: When this first came out, I recognized the limitations of pushing
serialized component state to the browser in a hidden form field but also
that browsers of that day and age didn't truly support long URLs. We have
come a long way since then, but this seems to still be a requirement within
this technology whereas I would have expected it to have been addressed
a long time ago. On the plus side, I think (though it has been a very long
time since I looked) that ASP forms are allowed to be sent using both POST
and GET ... if that is not true, I would appreciate hearing about it.
JSF: The spec starts out well by saying both multi-page forms and multiple
forms per page are a target of the technology. It then stumbles into only
defining POST oriented components and, from what I hear, the reference
implementation goes on to require that each page be wrapped in a form!
I am still searching for reasons behind these decisions. My current understanding
is that this is not for the hidden form field reasons that forms are critical
in ASP ... anyone know of reasons for the form decision (I understand why
one might only define POST oriented components, but I think it is shortsighted
... hopefully future updates will address this)?
Rich
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
---------------------------------------------------------------------
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]