[cgiapp] CGI::App Developing Runmodes Structure

[Mark Fuller]

On Sat, Apr 3, 2010 at 1:43 PM, John Cianfarani <jcianfarani at rogers.com>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