cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [PROPOSAL] mulitple actions per class
Date Wed, 13 Feb 2002 12:43:05 GMT

> Torsten Curdt wrote
> <snip>
> :), 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 "" which
with your syntax would be handled as a multiaction.

> > If I have a chance to see by looking into the sitemap which methods the
> > multiaction exposes (or which values are valid for the method attribute)
> > then I will change this to +0.
> But this means that you once define what is available inside the java code
> and need to mirror this inside the sitemap. This is more work than
> necessary and one of idoms of the sitemap was: (quoting Stefano from the
> docs) "minimal verbosity is of maximum importance" If someone is writing
> an webapp he should know about the classes he is using! If not - he could
> easily look this up in the javadocs. Actually I see this verbosity more as
> burden than helping.
> I guess it really depends on how the team is organized. Who is using
> these multiactions? And what goes in there? Actually I think these actions
> are different from the general purpose action that come with cocoon. They
> can be used to bind a java mehod directly to button on a web page.
> This becomes even more interesting if we also could use JavaScriptActions
> this way.
Ok, you're right that it depends on how the team is organized. I'm always
thinking of SoC, so one team writing java components and another team
"writing" the webapp by using the provided components. This second team
has no knowledge of Java and they don't know how to look into JavaDocs etc.
Now, it is of course possible to hand them documentation about the
which contains everything, but I personally would like to directly see it in
the sitemap as a requirement. documentation is the part of a project where
never anyone has time for.

> Of course having this inside action-sets is better than nothing...
> if noone objects I'd like to implement at least this new feature.

+1 (for action-sets)


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

View raw message