On Wed, 13 Feb 2002, Carsten Ziegeler wrote: > > > Torsten Curdt wrote: > > > > > > On Tue, 12 Feb 2002, Carsten Ziegeler wrote: > > > > > > Torsten Curdt wrote: > > > > <snip> > > > > > > > > > The verbose solution from above has the advantage that the > > > > sitemap editor > > > > > (the person writing the pipelines) sees which actions are available. > > > > > > > > Hm... that's true. But I guess these actions are would be > > mainly used for > > > > webapp purposes and will be used with the cocoon-action > > parameter anyway. > > > > Not inside the sitemap. ...but maybe we could provide both syntaxes? > > > > > > > Ah, you mean as an action-set, right? > > > So something like this (don't quote me on the syntax): > > > > > > <map:action-set name="mysuperactionset"> > > > <map:action type="multiaction" method="a" action="add"/> > > > <map:action type="multiaction" method="d" action="delete"/> > > > </map:action-set> > > > > > > For this I'm +1. > > > > > > But I'm not sure about a > > > <map:act type="multiaction method="a"/> somewhere in the pipelines > > > section. > > > > Yes, in particular for action-sets. Actually right now I am +0 for > > supporting it within the pipelines but for consistancy reasons I tend to > > +1. What would we tell someone on cocoon-users why it is not supported > > within the pipelines?! > > > > Is this also a +1 for the method-attribute syntax? ;) > > Hehe, nice try. No, sorry, it's rather a -0.
:) ...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) > 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. Of course having this inside action-sets is better than nothing... ...so if noone objects I'd like to implement at least this new feature. -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
