cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: [RT] was: [PROPOSAL] mulitple actions per class
Date Thu, 14 Feb 2002 11:17:18 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message