cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject [RT] was: [PROPOSAL] mulitple actions per class
Date Thu, 14 Feb 2002 10:22:26 GMT
> > <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">

...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...

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


Mime
View raw message