[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 mandatory? Stefan 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]