cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <>
Subject Re: [RT] was: [PROPOSAL] mulitple actions per class
Date Thu, 14 Feb 2002 10:45:29 GMT

Btw, there were a discussion on a topic related to action selection based
not only 'cocoon-action' attribute value, but in many other ways, e.g. one
can select an action/method to execute based on:

1) URL token: '/customer/*' -> action/method will be selected with {1}
parameter. E.g.: /customer/add, /customer/update, etc. This can be used in
links or 'action' attribute of HTML form.

2) Request param value (current implementation):
/customer?cocoon-action=Add - this has disadvantages, see below.

3) Request param presence: /customer?addBtn=Add: in this case checked the
param name, not the value, so you can have multiple submit buttons on the
screen: <input name="addBtn" value="Add" />, <input name="updateBtn"
value="Update" />

4) Any other value, e.g. sitemap param maybe returned from another action or
session/header/cookie, etc.

> > > <snip>
> > >
> > > :), I meant the syntax only - as you have given your +1 for use
> > > the action-sets. (BTW: I'd prefer the "action.method" syntax)
> > >
> > Ah, ok. I think the additional method attribute is more painless. I'm
> > sure, but I think I can currently define an action named ""
> > with your syntax would be handled as a multiaction.
> Carsten, I slept over this... and I found the attribute to be confusing.
> Here comes why: The original problem is that we want to pass more
> information via the one request parameter "cocoon-action" than the single
> name of the action. But all we have is *one* string. So for the request we
> can only choose from:
>   <!-- java object syntax -->
>   <input type="submit" name="cocoon-action" value="usermanagement.add">
>   <!-- html anchor syntax -->
>   <input type="submit" name="cocoon-action" value="usermanagement#add">
>   <!-- java inner class syntax -->
>   <input type="submit" name="cocoon-action" value="usermanagement$add">
>   <!-- (x)path syntax -->
>   <input type="submit" name="cocoon-action" value="usermanagement/add">

So, what will the end user see on his screen in this case? Buttons with ugly
names and what will you do in a multilanguage web application? You'll get
multilanguage method names ;)

> ...some kind of that. Of course we *could* use a different syntax in the
> sitemap but for consistancy reasons I would prefer to go with the java
> syntax and keep it through all the site. But this still brings up some
> confusion....
> Another thing is we have to be careful with the contract definition.
> What exactly is an action? Actually I think the current contract is not
> exactly what people would expect. Actions are expected to be executed. A
> component cannot be executed - a *method* of component can be executed.
> Unfortunately we cannot change this anymore... but people seem to get used
> to it:)
> But what if we would come up with event definitions? (this is borrowed
> from turbine ;) So a method is more an event on an action?
> *If* we change something on the current action handling or not. What I
> really like to see is get some additional information from the
> cocoon-action request parameter into the the action.
> Another idea: Maybe we could remove a postfix from the cocoon-action an
> add it as action parameter:
>   <input type="submit" name="cocoon-action" value="usermanagement/add">
> Will result in a call of action usermanagement with parameter
> "cocoon-action-parameter" set to "add"
> Mulitple actions per class could be implemented easily then...

So, why not to have a AbstractMultiAction class that will get method name as
a parameter? And all the descendant actions will only extend it will the
acting methods. What about this?

    Konstantin Piroumian
Leading Software Developer

Protek Flagship LLC
Phone: + 7 095 795 0520 (add. 1288)
Fax: + 7 095 795 0525

> What do guys think?
> --
> Torsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message