cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [PROPOSAL] mulitple actions per class
Date Tue, 12 Feb 2002 14:25:59 GMT
On Tue, 12 Feb 2002, Nicola Ken Barozzi wrote:
> > Although I'm not yet sure what syntax should be prefered
> >
> > 1.  <map:action type="SomeActions.doMyAction">
> >     <!-- directly use the method -->
> >
> > 2.  <map:action type="SomeActions.MyAction">
> >     <!-- have a fix prefix like "do" -->
> >
> > 3.  <map:action type="SomeActions" method="doMyAction">
> >
> > 4.  <map:action type="SomeActions" method="MyAction">
> >
> > Of course this will require the use of the reflection API
> > for those actions using the new method syntax. (All others
> > will not be effected and treated as usual)
> You can also use inner classes.

I have been thinking about this, too

There are quite some ways to do this... but as I said:
will this be confortable?

> > I have made some tests: if we use some intelligent
> > caching for the reflection API there will be only little
> > to no performance loss compared to the old mechanism.
> Jdk 1.4 has way higher performance in using reflection.


> IMHO a ClassMethodAction, with class name and methos name as parameters,
> would suffice.

...but how to use the "cocoon-action" parameter then?

If you have a form with multiple input buttons with action
bound to them you only have a single parameter:

  <input type="submit" name="cocoon-action" value="update">
  <input type="submit" name="cocoon-action" value="delete">
  <input type="submit" name="cocoon-action" value="add">

To change a hidden input field with javascript is not an option.
So the information which mehtod to be called must be encoded inside the
value which is currently the name of the action.

That's why I came up with something like this

  <input type="submit" name="cocoon-action" value="usermanager.update">
  <input type="submit" name="cocoon-action" value="usermanager.delete">
  <input type="submit" name="cocoon-action" value="usermanager.add">

Unfortunately I think this must be handled from Cocoon and just an
ClassMethodAction will not be enough

To unsubscribe, e-mail:
For additional commands, email:

View raw message