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 form params


Since my previous concerns seem not been understood I try to recap them
again:
1. The proposal introduces now a second field "encodedNamespace".
If I understood it correctly portlet are suggested to use the value of
namespacePrefix to namespace form field names and when getting the
interaction request back use the "encodedNamespace" for decoding the
params.
This seems odd. Further the current API have no means to get the
"encodedNamespace" at all. I.e. we break the current programming models.
The current programming models would use (besides the fact that it's
discouraged) namespacePrefix for encoding AND decoding.

2. If 1. is not true and we suspect that portlets continue to use
"encodedNamespace" not only for decoding but also for new encoding then we
introduce already a persistent namespace through the backdoor. Once the
porlet decides to use a namespace it would reuse the same thing over and
over again?

3. The problem does not solve the use case brought up to allow static
resources using wsrp_rewrite_ for form field names.
But I think this is still the undestanding here.
Why does it not solve it:
If a static resource (I woud also question the motivation here) namespaced
its form fields with wsrp_rewrite_ then the Consumer would rewrite it, i.e.
wsrp_rewrite_field1 becomes nsXfield1.
How can the target ever decode that with the current proposal.
The information of the used namespace does not flow back!
If it ever would want to flow back it needed to be part of the resourceURL
parameter in the wsrp URL. And we hopefully agree that resource URLs must
not be manipulated by the consumer.

So the proposal doesn't solve what it intended to solve given the
motivation that brought us to the idea of introducing it. Besides that, it
solves what can be solved otherwise - in my opinion - in a cleaner fashion.
Without the static resource use case things would already work today if we
introduced mandatory namespacePrefix fields as I tried to lay out.

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]