> Torsten Curdt:
> <snip>
>
> Hm... but then you always have to define each method of the
> class inside the sitemap plus you have to come up with all
> different names. So let's assume we have a usermanager class
>
> public class UserManagerAction extends SomeAction {
>
> public Map doAdd(...) {
> }
>
> public Map doUpdate(...) {
> }
>
> public Map doDelete(...) {
> }
>
> private void commonStuff() {
> }
> }
>
>
> Sitemap:
>
> <map:actions>
> <map:action name="usermanager-add"
> src="org.apache..UserManagerAction" method="doAdd"/>
> <map:action name="usermanager-update"
> src="org.apache..UserManagerAction" method="doUpdate"/>
> <map:action name="usermanager-delete"
> src="org.apache..UserManagerAction" method="doDelete"/>
> </map:actions>
>
> ...
>
> <map:act type="usermanager-add">
> ...
>
I really like the idea of your proposal and agree that the above is too
verbose and complicated.
>
> I think this is much to complicated and verbose for the
> sitemap. I see no benefit over:
>
> <map:actions>
> <map:action name="usermanager" src="org.apache..UserManagerAction"/>
> </map:actions>
> ...
>
> <map:act type="usermanager.add">
> ...
>
> Isn't this simple and straight forward?
>
This is simple, but how do I know which methods are available with this
action? And how do I know that this is a "multiple action class"?
The verbose solution from above has the advantage that the sitemap editor
(the person writing the pipelines) sees which actions are available.
Carsten
>
> The "do" prefix could make sure only desire methods can be used
> as action from a class.
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
