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

see comments inline in <rj></rj>

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

             Michael Freedman                                              
             @oracle.com>                                               To 
             09/06/2005 07:24          g                                   
             PM                                                         cc 
                                       Re: [wsrp-interfaces]               
                                       interactionFieldPrefix and          
                                       namespacing form params             

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
<rj>I don't think we discussed that at all yet. But I could easily imagine
requiring both to be that same. Consumers already should have a means to
identify their portlets on a page and I woudl assume this is the value (or
derived from it) they pass for namespace prefix and being used for
Besides this, I found it odd to have a portlet using both Producer writing
and Consumer rewriting.</rj>

   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"].
<rj>I never said that. In contrary, I even doubted that consumer do and
should rewrite opaque portlet state. So it's a plain portlet thing
completly transparent to the Consumer.</rj>

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

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.
<rj>This doesn't work.
Again, the portlet stores "ns.field1" in the form name and it shouldn't
expect to find just "field1" in the parameter map. This breaks all
exisiting implementations.
And the proposal requires additional parsing and stripping.
If the portlet is going to be stripping then the current APIs don't work
because portlets would need to have a means to obtain the

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.
<rj>No, I think that's wrong, because either we get assymetrie (Producer is
stripping the namespace) or we miss an API call to obtain the

I would like to see this proposal laid down in detail, i.e.
1. how do portlets encode the form names (how do they obtain the namespace)
2. how does it flow to the consumer
3. what is the consumer doing with it, especially in case of rewriting.
4. how does it flow back to the Producer
5. what is the producer doing there (stripping?)
6. how does the portlet obtain the form params again?
7. do static resources work?

Besides this, as I laid out in detail below (first mail) the intent to
support static resources with wsrp_rewrite_ in form names simply doesn't


Richard Jacob wrote:
      Here goes the proposal I had, just wanted to clarify it so people can
      up their mind.
      - 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
      they have today
      - do not require a constant prefix accross requests (although we coud
      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
      - 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
      I'm pretty sure other APIs will have similar means.
      There is no real penalty on the consumer, they can easily compute one
      page AND they already need some means for themselves anyway.
      So here portltes can encode their form field names using that
      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
      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
      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
      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
      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
      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
      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




                   09/06/2005 11:17          g


                                             Re: [wsrp-interfaces]

                                             interactionFieldPrefix and

                                             namespacing form params

      Hi all,

      I just decided to stress you further on the topic what we discussed
      week :-)
      I started to think through what we proposed and decided to give it a
      So here is what I understood as the general idea, please correct me
      if I'm
      - introduce a new WSRP url parameter containing the namespace which
      used by the producer container and passed to the portlets, e.g. if
      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
      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
      requests through the backdoor.
      Once the producer container decides to pick up a namespacePrefix from
      runtime context it is "persisted" in the URLs.
      The Consumer is forced to send it back -> Producer uses it again and
      it in the URLs.
      While this seems an interesting means at the first glance, it
      some problems.
      - How can consumers guarantee that they do not assign a new
      on a page which clashes with the existing ones?
      - How does this new value relate with the existing namespacePrefix,
      quite confusing here? Is the namespacePrefix assigned the new value
      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
      and rewrite it back again to wsrp_rewrite_ so that rewriting is
      used? -> additional producer rewriting
      - If not we have just one wsrp_rewrite_ usage and then fall back to a
      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
      Aren't parameter values opaque here? Do your rewriting implementation
      parameter values in a rewrite URL?
      3. Resources using URL rewriting
      I think the proposal doesn't really solve the problem. The main
      here is:
      - How does the namespace prefix assigned by the consumer flow back to
      - 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
      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
      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]