cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: [RT] was: [PROPOSAL] mulitple actions per class
Date Thu, 14 Feb 2002 10:45:29 GMT
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: kpiroumian@flagship.ru
http://www.protek.com

>
> What do guys think?
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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