I'm working on a medium sized CGI:A based web app here at work. It has about 70 or so rms. Each rm corresponds to one page, with a couple of exceptions. (more about these in a moment.) Unlike your setup, I also dedicate a run mode to processing each page that has inputs. These are imtimately related so that share a naming convention like:

• edit
• edit_proc

edit_proc validates input, and does something with the valid results. It would call edit if there were any user input errors and return that form to the user with errors indicated.

I've got a situation where two input forms are very similar, (creating a user, and modifying a user) They are just different enough that I have a unique run mode for each to set them up, but I use the same _proc to handle the inputs.

You posit:

you gotta control the users path. Lead them by the nose or they will get it all wrong!

This is a UI decision, which depends closely upon what you are trying to accomplish. Sometimes it is appropriate, othertimes no. In terms of CGI:A and how you code, it doesn't really matter, as you could support either. Supporting a lot choices is easy, just have them encoded in hrefs in the returned html. If you want to force the user on a path, just give them html that contains only a submit button with a hidden rm field indicating the next runmode.

Should "search, select, view and edit each be a separate run_mode"? Yes, in my opinion they should be seperated. Keep in mind that you can always factor out common code into an outside module for reuse across these runmodes.

Cheers

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday