cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: [C2] Action selection in sitemap
Date Mon, 12 Nov 2001 08:47:15 GMT
> On Thu, 8 Nov 2001, Piroumian, Konstantin wrote:
>
> You know that this breaks backword compatability and I havn't got your
> response onto mail my as I don't see how this fits into form base action
> selection where a button determines the action to take (these are not
> encoded into the URL path but as parameters).

Why do you think that this will break compatibility?
We can leave the old behavior as default and add this new functionality. I
don't think that adding new features will break somebodys' sitemaps if I
keep the old ones as defaults.

See my other response regarding this way of action selection.

Konstantin

>
> Giacomo
>
> > So, if no comments on this then I'll add this feature to sitemap. But
I'd
> > like to know if others also interested in something like this or there
is
> > another way for the same thing?
> >
> > Maybe this is more clear:
> >
> > <!-- A new attribute will make it possible to select actions without
using
> > hard-coded 'cocoon-action' request parameter, but depending on the URL:
> > /registration/Start
> > ...
> > /registration/Stop
> > here:
> > /registration - the matched action set
> > Start, Stop - the selected action
> > -->
> >  <map:match pattern="registration/*">
> >      <map:act-set type="registration-process" action-name="{1}">
> >           <map:read type="jsp" src="jsp/{current-page}.jsp"
> >       </map:act>
> > </map:match>
> >
> > Current implementation can be changed to a more flexible if we add an
extra
> > attribute to the action-set, e.g.:
> >     <map:act-set type="registration-process"
> > action-param-name="cocoon-action">
> >
> > > Hi, C2ers!
> > >
> > > I've already asked this question and it seems that nobody could answer
it.
> > > The question is: why the Environment interface has getAction() method
> > which
> > > returns the value of 'cocoon-action' (hard-coded) parameter from the
> > > request. It would be much better to be able to set the action name (or
a
> > > filter/pattern expression) in the sitemap. E.g.:
> > >
> > > <!-- For a registration process we have three actions: start, user
input
> > > processing, cancel -->
> > > <map:actions>
> > >     <map:action name="start-process"
src="regtest.StartProcessAction"/>
> > >     <map:action name="input-process" src="regtest.InputAction"/>
> > >     <map:action name="cancel-process"
src="regtest.CancelProcessAction"/>
> > > </map:actions>
> > >
> > > <!-- The action set for the registration process -->
> > >  <map:action-sets>
> > >       <map:action-set name="registration-process">
> > >            <map:act type="start-process" action="Start"/>
> > >            <map:act type="input-process" action="Input"/>
> > >            <map:act type="cancel-process" action="Cancel"/>
> > >         </map:action-set>
> > >  </map:action-sets>
> > >
> > > <!-- Entry point for all registration requests -->
> > > <map:match pattern="registration/*">
> > >     <map:act-set type="registration-process" action="{1}">
> > >          <map:read type="jsp" src="jsp/{current-page}.jsp"
> > >      </map:act>
> > >     <map:read src="html/error.htm"/>
> > > </map:match>
> > >
> > > So, requests will be of this form:
> > >     /registration/Start - the StartProcessAction will be called
> > >     /registration/Input - InputAction
> > >     /registration/Cancel - CancelProcessAction
> > >
> > > As you can see there is no need to use any '?cocoon-action=Start' or
so in
> > > the request and IMO using 'registration/Start' is much better - you
have
> > > clean separation of posted data and the action. I think, it will be
easy
> > to
> > > implement, but requires changes to Environment interface (remove or
> > > deprecate getAction()).
> > >
> > > The document that pushed me to this idea is related to Struts, but it
can
> > > apply also to C2 application development as well:
> > > http://husted.com/about/scaffolding/catalog.htm . Many good
> > > advice/hints/tricks from it could be used in C2 too.
> > >
> > > Are there any comments on this or other ideas?
> > >
> > > Btw, comparing Struts and Cocoon, I must admit, that Struts has much
more
> > > clear concepts and it's much easier in use and installation than
Cocoon.
> > The
> > > only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> > > capabilities and almost all its features are only a subset of Cocoon's
and
> > > can be easily implemented with C2.
> > >
> > > Best regards,
> > >
> > > Konstantin Piroumian
> > > Program Leader
> > >
> > > Protek Flagship LLC
> > > Phone: + 7 095 795 0520 (add. 1288)
> > > Fax: + 7 095 795 0525
> > > E-mail: kpiroumian@flagship.ru
> > > http://www.protek.com
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message