OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[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]