cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [C2] Action selection in sitemap
Date Fri, 09 Nov 2001 20:00:52 GMT
On Fri, 9 Nov 2001, Piroumian, Konstantin wrote:

>
> > > 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?

Carefull with this. The view concept is very fragile at the moment. It
could/will change in the future when there are semantic web crawlers
around which really need to use views. I'll say don't touch it ATM. One
way to go here would be to respect extentions as view names (ie:
resource.html, resource.xml, resource.xsd resource.rdf and of course
resource itself as the default view)

Giacomo

>
> 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: 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


Mime
View raw message