> On Thu, 14 Feb 2002, Piroumian, Konstantin wrote:
>
> > 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.
>
> Hm... I should play around with this one...
>
> > 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 ;)
>
> *doh* me stupid! We cannot use the value for that. The information must be
> hidden inside the name... damn - this is embarrasing
>
> But hey, this reveals a i18n problem with actions! The value must be a
> i18n value. So you would need action-sets for each language!! This must be
> changed anyway! I guess we need to do this somehow like the turbine guys:
>
> <input type="submit" name="cocoon-action-[actionname]"
value="Hinzufuegen">
>
> While changing this I could easily add the paramter stuff to work the same
> way as you propose with URL stuff below.
>
> <input type="submit" name="cocoon-action-[actionname]/[parameter]"
value="Hinzufuegen">
>
> The /[parameter] could be optional and be translated into an action
> parameter named "cocoon-action-parameter". What do you think?
Yes, this is a way to solve this, but why not simply use something like an
ActionSelector, which can be used to extract request params in any way you
like and expose them to sitemap. E.g.:
<map:act name="ActionSelector">
<map:action-set name="my-actions">
<map:parameter name="method" value="{method-name}" />
</map:action-set>
</map:act>
See my previous mail about conditional action-sets.
>
> > > ...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?
>
> ...with the URL method... yes, this should work. But I had to restructure
> all our sitemaps :(
You should do it anyway if you extend sitemap syntax.
Konstantin
> --
> 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]
