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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsrp-interfaces] interactionFieldPrefix and namespacing formparams

I agree with Richard's proposal to keep it simple and not change the 
overall programming model.

While we are looking at the ids provided in the runtime context, can we

- specify what chars are allowed to be used in the namespace string?
- consider making the portletInstanceKey also mandatory? Why is that not


Richard Jacob wrote:
> Here goes the proposal I had, just wanted to clarify it so people can make
> up their mind.
> Rationales:
> - do not require form params namespacing
> - do not prevent portlets from doing it (but don't add an extra penalty on
> those who don't want to do it)
> - do not change portlet programming models, allow them to use the means
> they have today
> - do not require a constant prefix accross requests (although we coud talk
> about it, portletInstanceKey is already someting similar)
> - have a symmetric model, i.e. portlet gets back what it encodes
> - try to avoid unnecessary rewriting steps
> The whole proposal simply bases on two facts:
> - why not force consumers to always provide a namespace prefix? today it is
> optional
> - using wsrp_rewrite_ for form param names is problematic and should not be
> used (we discussed it already)
> 1. Consumer always provide namespacePrefix
> This way Producer can rely on it and always return the prefix to the
> portlets if the request it, e.g. they call getNamepace() in the JSR168
> case.
> I'm pretty sure other APIs will have similar means.
> There is no real penalty on the consumer, they can easily compute one per
> page AND they already need some means for themselves anyway.
> So here portltes can encode their form field names using that namespace.
> The only thing they need is to remember the prefix they used.
> This can easily be stored in the portltet's interactionState.
> This is completly transparent to the consumer AND producer and doesn't
> require any additional rewriting, parsing, stripping etc.
> 2. do not use wsrp_rewrite_ in form parameter names
> a) there is no need for it if we have 1.
> b) as said it is very problematic, and was not the initial intent of
> wsrp_rewrite_. The intent was to namespace *one time* the markup without a
> flow back. It seems the stretch we want to do here is to large.
> c) in fact portlets using getNamepace() and 1. will never see a
> wsrp_rewrite_ anymore, so from a dynamic UI generation point of view there
> is no need to use wsrp_rewrite_
> d) portlets with static content can still use wsrp_rewrite_ as they use for
> 1.0 we don't break anything
> 3. the resource discussion we had last thursday
> The proposal on the table doesn't solve the problem anyway as I described
> below.
> Let's think through it:
> - in 1.0 it never could work and indeed we discouraged people from
> namespacing form field names.
> - if a resource (e.g. servlet) uses wsrp_rewrite_ we really can consider it
> as being "WSRP aware", i.e. we can't claim that in this case the resource
> is completly WSRP agnostic.
> - if the above is true why not pass the "WSRP context" to the resource via
> the resource URL. In this case why not pass the namespacePrefix to the
> resource?
> This is how it could work:
> 1. portlet gets called and obtains the namespacePrefix
> 2. portlet encodes a resource URL and as a parameter passes the
> namespecePrefix to be used (indeed it needed to be a subSpace of the
> initial namespace in the case the portlet AND the resouce generate forms -
> use case?)
> 3. resource received ns prefix can use it, can also encode the prefix used
> by various means.
> Mit freundlichen Gruessen / best regards,
>         Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Team Lead & Technical Lead
> WSRP Standardization
> Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
> Email: mailto:richard.jacob@de.ibm.com
>              Richard                                                       
>              Jacob/Germany/IBM                                             
>              @IBMDE                                                     To 
>                                        wsrp-interfaces@lists.oasis-open.or 
>              09/06/2005 11:17          g                                   
>              AM                                                         cc 
>                                                                    Subject 
>                                        Re: [wsrp-interfaces]               
>                                        interactionFieldPrefix and          
>                                        namespacing form params             
> Hi all,
> I just decided to stress you further on the topic what we discussed last
> week :-)
> I started to think through what we proposed and decided to give it a shot.
> So here is what I understood as the general idea, please correct me if I'm
> wrong:
> - introduce a new WSRP url parameter containing the namespace which was
> used by the producer container and passed to the portlets, e.g. if they
> call getNamespace()
> - we assumed implicitly that the value of the new param is flowing back (in
> InteractionParams and MarkupParams?)
> What does it bring/help or was the intent of it?
> - do not require namespacePrefix to be mandatory
> - allow usage of wsrp_rewrite_ as the namespace prefix, here we explicitly
> refered to resources using rewriting
> - do not require the namespacePrefix to be constant across requests
> - anything I missed?
> I've been playing a little bit with it, here are some thoughts
> 1. portlets do not use wrsp_rewrite_ for form params namespacing
> - it seems we're introducing some kind of namespace persistance across
> requests through the backdoor.
> Once the producer container decides to pick up a namespacePrefix from the
> runtime context it is "persisted" in the URLs.
> The Consumer is forced to send it back -> Producer uses it again and stores
> it in the URLs.
> While this seems an interesting means at the first glance, it introduces
> some problems.
> - How can consumers guarantee that they do not assign a new namespacePrefix
> on a page which clashes with the existing ones?
> - How does this new value relate with the existing namespacePrefix, seems
> quite confusing here? Is the namespacePrefix assigned the new value from
> the URL?
> 2. portlets using wsrp_rewrite_ in form names as the ns prefix
> We saw that this is quite problematic. The intent of the proposal using the
> URL param was that the URL param itself gets rewritten by the consumer to
> the "real" namespace as well as the form fields in the markup. Thus
> portlets/the producer can obtain the consumer assigned namespace to
> identify the form params.
> - Do we expect that Producers in this case pick up the assigned namepace
> and rewrite it back again to wsrp_rewrite_ so that rewriting is always
> used? -> additional producer rewriting
> - If not we have just one wsrp_rewrite_ usage and then fall back to a given
> namespace prefix with the implication I described in 1. ?
> - I think we change the rewriting algorithms here: What do consumers do if
> the wsrp rewrite token appears as a parameter value in the rewrite URL?
> Aren't parameter values opaque here? Do your rewriting implementation touch
> parameter values in a rewrite URL?
> 3. Resources using URL rewriting
> I think the proposal doesn't really solve the problem. The main question
> here is:
> - How does the namespace prefix assigned by the consumer flow back to the
> reasource?
> - If it needed to flow back to the reasource it needs needs to be part of
> the resource URL not the rewrite URL. But as of today, resource URLs are
> opaque to the Consumer and it shouldn't touch them.
> So when thinking through it, things really seem to become clumsy here, too
> with not adding to much value here.
> There are some implication in the proposal, which haven't been thought
> through, yet.
> Mit freundlichen Gruessen / best regards,
>         Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Team Lead & Technical Lead
> WSRP Standardization
> Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
> Email: mailto:richard.jacob@de.ibm.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]