> > 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.:
> >
> >
<skipped>
> > So, requests will be of this form:
> > /registration/Start - the StartProcessAction will be called
> > /registration/Input - InputAction
> > /registration/Cancel - CancelProcessAction
>
> Of course this is a way to go. Can you give an example if the actual
> action request is comming from a html button in a form (is encoded as a
> parameter instead of URI-path)?
The action request comes from different HTML forms but processed by the same
matcher "registration/*". Which button caused this submit in this case is
processed internally by the appropriate action.
After thinking a little more I came to this three ways of determining the
action:
1 an URL part (all buttons are processed by the action)
2 action parameter (like 'cocoon-action' - one param name - multiple
actions)
3 different parameters (e.g., three buttons with different names on a
form. It doesn't matter what the value is - we need to check if the
parameter is present)
The first case is useful when you have a single action for all buttons on a
form (e.g. the actual processing is performed on the back-end and you don't
care which button had been clicked, e.g. in an EJB or Workflow application).
The second case is currently used in C2, but the main disadvantage of it is
that you depend on the button value, which is an issue in a multilanguage
application (alternatively, a hidden field with JavaScript can be used -
this is not a good solution either)
The third case IMO is best: you have as many buttons as you like, and any
labels (values) - you only get one button on submit and you check which one
of the possible params is present.
So, I can suggest to improve C2 action selection mechanism to support all 3
cases. It seems to me that it will require some changes in interfaces and
not so easy to implement (from the first look).
Btw, 'cocoon-view' parameter name is also hard-coded. Maybe it'll be better
to invent some kind of a selection mechanism (instead of using sitemap
selectors) based on attributes for things that depend on request parameter
names, values and presence?
Regards,
Konstantin Piroumian
>
> And, yes, patches are welcome.
>
> Giacomo
>
> >
> > 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]
