Because of consumer environments that rely on ASP.NET or JSF we will
see interest on the part of some portlets to render themselves to
minimize the work these consumers need to do to agreegate them into the
page. We need to adapt our protocol to support these portlets. What
do you think of the following solution?
Introduce a new RuntimeContext field called
formFieldPrefix. This field is defined as "This field provides a
useful string for the Portlet prefixing of form field names. Use of
such a prefix will guarantee uniqueness within the context of the
consumer aggregation across all requests."
Notes: It should be easy for the consumer to manage this id as it is
derivable from the "portlet window id"/view id of the portlet in the
page. I.e. its related to "portletInstanceKey" and derived from the
same state.....Also, for the moment I have omitted proposing whether
the consumer or the producer is responsible for dealing with/removing
the prefix when the form is submitted. At the moment I lean towards
making it the Producer responsibility as this is symmetric and supports
the widest diversity of implementations.
Benefits of this proposal:
- Doesn't change existing WSRP semantics -- hence producers that
aren't interested in this can merely ignore this new field/mechanism.
- Avoids using rewrite-token to add prefix. Asking the consumer to
add this token kind of defeats the purpose in the first place, which is
to improve efficiency/effectiveness of consumers adapting this into a
page with an all-encompassing form.
By the way, for those who find the above too HTML specific for
RuntimeContext an alternative is to define a new structure called
MarkupContext that is passed in MarkupParams. This field would be
optional and of type ANY. We would define specific MarkupContexts per
markup type [e.g. HTML] that convey extra information useful to the
portlet for generating its markup. For the moment we would only define
an HTMLMarkupCotnext with a single field: formFieldPrefix. But it
would be easy to add such things like whether the producer is
aggregating the portlet into an form, etc.
-Mike-
Richard Jacob wrote:
Hi,
I'm catching up with the originating thread "Portlets and Forms".
I'm not quite confident that the proposed namespacing of form fields really
solves the nested forms problem discussed there.
I have the following concerns:
1. don't we change the programming model for portlet developers?
We now seem to [likely] encourage them to namespace form fields while we
didn't in v1.
Typically our customers want to develop portlets (or whatever component
technology they use) and ["simply"] provide these as WSRP remote portlets.
They don't really care about nuances of the WSRP protocol but want their
components simply work over WSRP without any change to their component
code. E.g. when we think of JSR168 portlets,
programmers don't use encodeNamespace() for their form fields in their code
because we and the JSR168 told them not to do so.
Now we are reverting it and tell them they have to use a different
programming model to make their portlets work over WSRP.
This seems broken to me. In this case portlets won't work out "of the box"
any more over WSRP.
2. Does the mandating of namespacing form fields really solve the problem?
It doesn't seem so to me. As Andre said, and I agree, the really feasible
way today for the Consumer to enable the UI technologies like ASP and JSF
is to rewrite the markup.
Or alternatively provide helps to accomodate such a transformation like you
suggested (but still might be difficult to tell whether portlet markup
contains forms or not unless the underlying component technologies provide
such information without the need of parsing the markup on the producer
side).
What do we gain if we enforce the namespacing of form fields? As far as I
understood the current proposal the Consumer would have to parse the markup
anyway (e.g. to remove the the form tag,)
3. I think the (in the case of namespacing of form fields, legitimate and
correct) questions below indicate that we now have a change of semantics
concerning namespacing.
While in V1 the namespacing purpose was to protect java script functions,
variable names etc. from name clashes and misfunction of these javascripts,
we now extend the model quite a bit.
In the v1 case the namespacing was just for the purpose of "collision
prevention" and effectivly was used when the complete page was rendered,
either via wsrp_namespace or the namespacePrefix in RuntimeContext. And
this was scoped by the aggregated page and was "always" valid, i.e. at the
generation time we assured that we don generate pages with colliding names
- that's it.
Now we add a nuance of lifetime to such prefixes as you correctly
identified.
This is because we now have to assume that the prefix used by the consumer
is kind of persistent, right?
I'm not sure if we want to enforce that.
Typical use case might be: Consumer has generated a page with 4 portlet
windows, Browser bookmarks page, Admin removes one portlet from the page.
Now the window ids might habe changed..., browser access the bookmarked
page.
If we decide to not to enforce persistence of the prefixes, it will be hard
for the consumer to strip them. I think in this case the consumer would
need to store them in its state in the URL.
Therefore I really would question if this namespacing really helps us.
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
<michael.freedman
@oracle.com> To
wsrp <wsrp@lists.oasis-open.org>
07/08/2005 02:08 cc
AM
Subject
[wsrp] namespacePrefix
Now that we no longer discourage portlets from namespacing form field
names [and likely will encourage it], do we need to clarify further how
namespacePrefix works across requests? I believe we finessed this is v1
because we didn't believe things that would be resubmitted to the
consumer through to the producer would be namespaced -- now they
can/will be. If the portlet uses the wsrp_rewrite_ namespace rewrite
token for a field name is the consumer responsible for stripping the
namespace on subsequent form submit? If the portlet uses the
namespacePrefix in the RuntimeContext does the consumer likewise remove
it on form submit? Or must is guarantee that the namespacePrefix passed
in the RuntimeContext of the submit request be identical to the one it
supplied before? How long does it have to ensure this behavior?
-Mike-
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|