> > <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.
Makes sense! > > > 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 > multiaction I hear you. SoC are important but I'm wondering: isn't it a bit over separating and hindering if you always have to ask for the specific actions and wait for the java team to write them?At least for us here there are no such clear distinc groups to separate... Lets say they need action that is supposed to check a request value if lesser than, greater than or equal 0. This what we call flow actions. They are really REALLY simple and a component for such simple flow decisions doesn't make much sense. (That's why I came up with this idea;) > 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. I know...*sigh* good for us at least the basic javadocs are generated automagically :) > > 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. > > +1 (for action-sets) ok :) -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
