[snip] > Josh, I am interested in what you mean by "but there may be a better > overall approach." The reason I say that is because, though I'm no expert on application design, in my own code I've found that whenever I'm tempted to use a big switch, it's probably a better idea for me to make a class hierarchy. I just have a hard time imagining a case where a big switch accurately represents the problem to be solved, since in real life solving problems is more complicated than a flat set of totally isolated operations. [/snip] The switch in this case is being used by the application as you would a main() in C++ to a large degree. Here is an example.... error checking and validation (ECV) function / class is loaded at the top because it can be used for all switch cases; database connection module is loaded at top, it can be used for all switch cases form A is handled by case A. form A is unique in the tables that it utilizes. form B is handled by case B. form B is unique in the tables that it utilizes. and so on...perhaps 20 - 30 forms Also, the completion of form A may dictate that n more forms must be completed. The user completing form A needs only to see the forms designated during the processing of form A. In a couple of cases subsequent forms will require the successful completion of additional forms. The forms in this case are quite independent of each other from a processing point of view. They do rely on certain holistic items, such as ECV and DB connections that are also held in seperate files. As for management. Since there are several developers working on the project this method of management works quite cleanly. Each can complete isolated form coding without disturbing another developer's progress. All have applications flowcharts and have the hooks to the ECV API and DB connection API. If a module needs to be taken "off line" it does not affect the operation of the remainder of the application. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
