Re: [wsrp-wsia] [I#179] requestParameter semantics unclear

[Carsten Leue <CLEUE@de.ibm.com>]

Mike - I think that this is a very comprehensive writeup of the different
types of state.
A brief comment to your a) and b) questions:

a) I agree that in principal the navigational state that currently flows to
the blocking action could be modeled in the interaction parameters. But you
could also see a (minor?) distinction if you view the navigationalState as
the intrinsic state of the (logical instance of the) portlet object - so
state of the model - and the interaction parameters as modificators - so
state of the controller. The interaction parameters can be used to apply a
controller to the portlet. The result is a modifed (not a new) navigational
state.
So I would vote for leaving navigational state a part of the input
parameters of blocking actions
b) I would say that this is a leftover from a time when we did not have
nonblocking actions.

Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



                                                                           
             Michael Freedman                                              
             <Michael.Freedman                                             
             @oracle.com>                                               To 
                                       wsrp-wsia@lists.oasis-open.org      
             01/06/2003 11:11                                           cc 
             PM                                                            
                                                                   Subject 
                                       Re: [wsrp-wsia] [I#179]             
                                       requestParameter semantics unclear  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Yes, it looks like we have lost some clarity when we added the ability for
actions to return markup.  However, I don't think this requires we separate
query string and form (post) parameters into separate fields.  As a review,
here
is my understanding of what we have been trying to model:

We distinguish between 2 types of state parameters passed to a portlet.
One
type is called navigational state.  The other is interaction state.
Navigational state is the state passed by the consumer to the producer that
allows it to render [over and over again].  I.e. its the "bookmarkable"
state
carried by the consumer [and possibly the client].  Interaction state is
the
"transient" state utilized in actions to affect change.  I.e. in a
simplified
view:
      A blocking action receives interaction parameters and returns
navigational
state.  This navigational state is passed to the subsequent getMarkup (and
follow-on rerenders), but the interaction parameters are not.
      A non-blocking action receives interaction parameters but isn't
allowed to
alter navigational state.  The navigational state passed to the subsequent
getMarkup is the one encoded in the non-blocking action request.  Like the
blocking action, the interaction parameters aren't passed along to the
Getmarkup.
      GetMarkup should only receive navigational state.  Like a
non-blocking
action it can't alter/return new navigational state.

Currently, URLs written by the portlet into its markup contain 2 types of
parameters.  Navigational state is encoded by placing such state in the
value of
the special parameter "wsrp-navigationalState".  Interaction state is
encoded as
extra query string parameters -- i.e. any query string parameters not
reserved
by wsrp.  In addition if the URL is the action of a form, the form
parameters
are also considered interaction state.

Though I know the bulk of this discussion thread has concerned itself with
[whether or not] to distinguish between interaction state encoded in the
query
string vs. as form parameters I think we should really be focusing on
properly
distinguishing between navigational state and interaction state.  For
example:
    a) Why do we allow a blocking action URL to explicitly carry the
navigational state since a blocking action is now required to return new
navigational state if it wants any?
    b) Why do we allow a render URL to carry extra parameters not in its
navigational state?

A "pure" model based on my descriptions above might work something like
this:

A blocking action only encodes interaction parameters -- any previous
navigational state that needs to be passed to the action is represented in
predefined interaction parameters.  If we keep to the current model, these
interaction parameters are signified in the rendered URL as query string
parameters whose names aren't from the reserved list.  Alternatively we
could
simplify things and use a interactionState token [ala navigationalState].
The
benefit of doing this alternative is that any portlet specific parameters
in the
URLs query string MUST be namespaced while this can be avoided if we hold
these
parameters using a reserved name.

When the blocking action is called it receives the parameters in its
InteractionParams data structure.  I.e. though it receives a MarkupParms
structure [so it can render if it wants to], the navigational state in this
structure is NIL [pending the return from the blocking action].  Likewise,
as
getMarkup only receives navigational state the current field
requestParameters
is removed.  To hold this information in InteractionParams I propose we
expand
the structure to hold both binary data and form data.  A field would be
added to
distinguish the type of interaction parameters are passed.  When form data,
I
would propose all parameters be collapsed into a single parameter array
though
we can continue discussing the merits of differentiating between those in
the
query string and those in the posted form.

The blocking action processes the action based on the passed parameters and
returns new navigational state [if needed] and if optimized the actual
markup.
We leave it up to the portlet/action to properly encode/model this new
navigational state to its optimized getMarkup call.

A non-blocking action encodes both interaction parameters and navigational
state.  The interaction parameters are used during the non-blocking action.
The
navigational state is the predefined state used for the subsequent
getMarkups
[as no new navigational state can be returned].  When the non-blocking
action is
called it receives the interaction parameters in the InteractionParams data
structure as described above.  In addition it receives the navigational
state in
the MarkupParams structure.

Finally, the render [getMarkup] only deals with navigational state.  Thus
only
navigational state can be represented in generated render URLs.  Likewise
getMarkup only receives the MarkupParams structure.

        -Mike-



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>