[cgiapp] CGI::App Developing Runmodes Structure

[Mark Fuller]

On Sat, Apr 3, 2010 at 9:30 PM, John Cianfarani <jcianfarani at rogers.com> wrote:
>  In your examples which
> run modes would display do things like the page with "add / delete / report"
> or the login page?

Not sure I understood that. But, for me, the absence of a runmode
tells me it's a new display, not an action resulting from a form
submit.

If the "asset" module's runmode "add" is expected to display a form to
add assets, I just determine in the setup method whether the the
module is being called as a result of the form's submit button being
pressed. I do that instead of setting a runmode to precisely identify
the state unique state (like "add_submit" which would be treated
differently than "add_display").

If the add/delete/report runmodes had a lot of features within them, I
might make each one their own module, each with runmodes. Like,
asset/report?rm=lost_assets

> 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.

Maybe it's just personal preference. To me, the state of a runmode is
already available in the submit button's value. I don't need to add
that information to the runmode's value, creating a state-unique
runmode (like "add_submit").

For me, one positive is that a visitor can bookmark asset?rm=add and
the page will do the right thing when they go there. There's no chance
that they would bookmark asset?rm=add_submit, and me display a page
with error messages about required fields.

(That's why I consider the URL --- if the way I carve up
modules/runmodes/states makes sense as a URL.).

You might also look at the "c::a::dispatch" plug in, which treats
paths like runmodes. (i.e., asset/report/lost_assets). I haven't used
it. But, that path structure might give you an idea how to to look at
c::a's native runmode.

Mark