On Sat, Apr 3, 2010 at 1:43 PM, John Cianfarani <[email protected]>wrote:
> > In one faq page it says to stay around the 4-12 runmodes for a project am > I > creating too many? How would you deal with multiple pages to edit? > > > You can have multiple modules, each with multiple run modes. So, you might have: module: login rm: new rm: renew (after timeout, if that condition makes a difference) module: register rm: create rm: confirm (user responds with value from email) module: profile rm: edit module: asset rm: add rm: delete rm: report module: site rm: logs rm: warn_user rm: user_groups I try to balance runmodes and modules so they make sense as a URL. (Object, and parms related to the object). Using paths, you could organize things even further (more meaningful URL). Like session/login, and user/register, user/profile, site/logs, site/warn_user, site/user_groups. For me, I don't go crazy with a unique runmode for every thing that might happen on a page. For example, if a page is editing user profiles, but has another form button to lookup values, I just call the same runmode for editing user profiles and determine (in the setup method) which submit button was pressed. That keeps runmodes from getting out of hand. I think of object, major behaviors (runmodes) of an object, and then states within a behavior (first-time display, responding to a submit, which submit, displaying page with errors? Determined from form variables, or lack thereof.). I don't know if that addresses what you were asking. Or, if my way is the correct way. But, that works for me. Mark ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
