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?
> > ...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 :(
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
