Actions and ActionChains

[Overunner]

I've (somewhat) come to the conclusion that my application I'm currently developing has 3 'kinds' of actions.

1. A 'regular' action which executes some buisness logic and returns a view. Nothing special.

2. An action which only executes some buisness logic. This could for instance be the 'DeleteProductAction'.

3. An action which actually does neither. This could for instance be the 'AddProductAction'. When the action gets performed it only checks whether the user has submitted a valid form (valid productname, price, etc.). The action then forwards to either 'AddProductSuccessfullAction', which inserts the product in the DB, or 'AddProductFailureAction' which returns a 'FailureView'.

Code example:

// Product controller

    function &getAction($action)
    {
      switch($action)
      {
        case 'AddProduct': // Action of type 3

          $validator = new Validator(new Request());
          // Add rules, validate, etc
          if ($validator->isValid())
          {
            // Perform the AddProductSuccess now instead.
            $this->forward('AddProductSuccess');
          }
          else
          {
            // Perform the AddProductFailure now instead.
            $this->forward('AddProductFailure');
          }

        case 'AddProductSuccess': // Action of type 1
          return new AddProductSuccessAction();

        case 'AddProductFailure':
          return new AddProductFailureAction();

        case 'ShowProduct':
          return new ShowProductAction();

        case 'DeleteProduct': // Action of type 2
          // Delete the Product and then show the products by performing the ListProductsAction! (Need some kind of actionchain?)
          return new DeleteProductAction();

        case 'ModifyProduct':

          $validator = new Validator(new Request());
          // Add rules, validate, etc
          if ($validator->isValid())
          {
            return new ModifyProductAction();
          }
          else
          {
            return new FailedModifyProductAction();
          }

        case 'ListProducts':
          return new ListProductsAction();
      }
    } 

It is kinda complicated to implement an actionChain since some action has views, some does not, and some doesn't even do anything (almost!). My 11th sense tells me that having 3 types of actions isn't gonna make my life easier.
Anyone has a solution to this?

[sweatje]

I don't know if it helps or not, but I always had exactly 1 type of action. My business logic would always issues a redirect, eventually to a "ShowView" action, which could make an intelligent choice about which view to show. For example, an "AddProduct" action could easily choose which view the next "ShowView" action should display.

HTH

[Dr Livingston]

I've noted previously SweatJe that you do a redirect, and I've looked into this myself to prevent the problem when you click refresh on a form submission... It seams to work but it means you need to persist $_POST variables via a session variable

But I'm still testing the practical implications just now, could you post some script as examples? I can see where Overrunner is coming from, from the stand point of having to delegate an action, but I feel a CoR may help...

Thanks.

[algis]

hi Overunner,
I've implemented actions and actionchains in a somewhat different way:
I don't split actions in types. Instead I define a class "actionResult". An action may return an actionResult or nothing. For example, I update an object from the form. A controller triggers a "update" route (by the way, I've implemented sort of configuration file rather than messy switch() statements that quickly become unbearable) that I make as a chain of several actions:

checkFormData
checkIfObjectDataHaveBeenChanged
updateObject

A controller runs the first of actions. As we remember, it may return actionResult or nothing. If it returns an actionResult (I've got another configuration file for them) - like formDataIsWrong - it redirects to the respective view (taken from my conf file) - in this case, an error message, and quits the chain. If it returns nothing, I assume that this step went smooth and we can jump to the next action in chain. So it runs checkIfObjectDataHaveBeenChanged and if it's ok, finally goes to updateObject. The last action in chain should return an actionResult of some kind, so usually updateObject returns an objectUpdated actionResult that shows an "OK" message and redirects to some other view - may be show the updated data for the object or something.

[arborint]

It looks to me like all of your actions are the same. The Controller selects an action which does the Business Logic and then displays a view based on the results. I think the things you call 'AddProductAction' and 'AddProductSuccessfullAction' are either Transaction Scripts or just controller states.