> While working with actions something bugs me more and more... For each
> very simple action you need to have a new class. Although it might be just
> a few lines for each, it becomes really ugly when you share code with
> other actions or need to call an action from an action. Plus having
> thousand of action class for a single webapp. Sure this all possible and
> one can say: then use helper classes that hold all the shared code. But
> well - possible does not mean confortable.
Another possibility is to use a request or sitemap parameter with an
aggregated Action, e.g.:
<map:match="cart/*">
<map:act name="CartAction">
<map:parameter name="action" value="{0}" />
</map:act>
</map:match>
So, for requests like: 'cart/add', 'cart/remove', 'cart/update' you can use
a single action that performs something like:
act(...) {
if (ADD_ACTION.equals(actionName) {
// do addition
} else {
...
}
// etc.
}
>
> IIRC with Turbine e.g. it is way more confortable. They use
> "methods as actions":
>
> class SomeActions {
>
> public void doMyAction(..) {
> ...
>
> (I'm not quite sure about the arguments and stuff though)
> This helps to have all related code at a glance.
> Although I'm not yet sure what syntax should be prefered
>
> 1. <map:action type="SomeActions.doMyAction">
> <!-- directly use the method -->
>
> 2. <map:action type="SomeActions.MyAction">
> <!-- have a fix prefix like "do" -->
>
> 3. <map:action type="SomeActions" method="doMyAction">
>
> 4. <map:action type="SomeActions" method="MyAction">
I would use a substitution param for setting the 'method' value. You can
select the action to be performed based on request path, request parameter,
maybe even another action. E.g. depending on the time of day or the day of
week you can perform the action in a different way and another action will
define what method to perform.
>
> Of course this will require the use of the reflection API
> for those actions using the new method syntax. (All others
> will not be effected and treated as usual)
>
> I have made some tests: if we use some intelligent
> caching for the reflection API there will be only little
> to no performance loss compared to the old mechanism.
>
> What do guys think?
> --
> 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]
