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).
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: [EMAIL PROTECTED]
> > http://www.protek.com
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
