[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] interactionFieldPrefix and namespacing formparams
Hi Mike, I think I missunderstood the interactionNamespacePrefix. From you note I conclude that this prefix represents the namespace used when the markup was generated. Thus you would not be allowed to use the interactionNamespacePrefix to do anything else than decode the submitted parameters (i.e. you cannot use it in the current markup the portlet generates) as it may not be a valid namespace for the current request, correct? Missing the V 1.0 discussion I still don't quite understand the use case of prefixing static forms with the rewrite token. If you need to add anything to the static form, like the rewrite token, why not add some javascript that inserts the current namespace? Stefan Michael Freedman wrote: > I had trouble understanding the points you were trying to make as you > shortcutted some of your thoughts. However some basic responses: > > 1. I think we said that the reason we supported both wsrp_rewrite_ > and the namespace prefix in WSRP 1.0 is because we didn't > assume/require these value be the same. If they aren't the same, > then a portlet whose markup is partially constructed > programmatically and partially from static files needs to use the > same prefix in both locations [if one references the other -- for > example javascript function reference/implementation.]. For > static files wsrp_rewrite_ is the only choice for namespacing > items. For the situations above, the programmatic generated > response would be wise to also use wsrp_rewrite_. > 2. The solution proposed last week was introduced for two reasons: > it makes such encoding transparent vs relying on the developer to > understand the subtlety that namespacePrefic values may change and > count on them to manually encode the prefix in opaque state; it > avoids the question of whether all consumers recognize the rewrite > token in portlet encoded opaque state [assuming of course the > producer has written this in "plain text"]. > > As for the issues you raised -- again I don't think I understoof all of > your concerns but here is what I expect from the proposal we made last week. > > The "interactionNamespacePrefix" token we would allow portlets to > optionally write into the interaction URLs and/or resource URLs [that > call getResource] would be described as something like: "represents the > namespacePrefix used to encode interaction elements [form fields] > delivered with this interaction. This enables portlets to identify and > remove such prefixes in order to return the elemtns name to its original > representation.". I.e. basically our model is use > runtimeContext.namespacePrefix/wsrp_rewrite_ to encode names when > generating markup, use the interactionNamespacePrefix to decode such > names in a subsequent interaction from that generated markup. > > Finally, I don't think our proposal changes the programming model at all > for any WSRP 1.0 portlets. They continue to operate/be coded exactly as > they are today. It does however simplify/clarify handling namespacing > interaction fields. > -Mike- > > 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]