[cgiapp] CGI::App Developing Runmodes Structure

[John Cianfarani]

Thanks for the reply, I wasn't really thinking too much about the URL
itself, beyond the fact that each module would be a high level url /login.pl
/user.pl /sites.pl etc... I was thinking that the run mode would be a hidden
tag on the page.  

Maybe I'm thinking about run modes in the wrong way, in my mind they are the
way to distinguish "exactly" what needs to happen.  In your examples which
run modes would display do things like the page with "add / delete / report"
or the login page?  What would be the drawback to creating several run modes
for each item?  It seems like it's a tradeoff of setting another param to
check essentially creating a sub run mode.

Thanks for the help
John

-----Original Message-----
From: cgiapp-bounces at lists.openlib.org
[mailto:cgiapp-bounces at lists.openlib.org] On Behalf Of Mark Fuller
Sent: Saturday, April 03, 2010 7:52 PM
To: CGI Application
Subject: Re: [cgiapp] CGI::App Developing Runmodes Structure

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

#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################