Hi!
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>
> > >
> > > :) ...no, I meant the syntax only - as you have given your +1 for use
in
> > > the action-sets. (BTW: I'd prefer the "action.method" syntax)
> > >
> > Ah, ok. I think the additional method attribute is more painless. I'm
not
> > sure, but I think I can currently define an action named "hello.you"
which
> > 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?
Regards,
Konstantin Piroumian
Leading Software Developer
Protek Flagship LLC
Phone: + 7 095 795 0520 (add. 1288)
Fax: + 7 095 795 0525
E-mail: [EMAIL PROTECTED]
http://www.protek.com
>
> What do guys think?
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
