[cgiapp] CGI::App Developing Runmodes Structure
ron at savage.net.au
Sun Apr 4 19:43:12 EDT 2010
Hi John, Mark
On Sun, 2010-04-04 at 04:22 -0700, Mark Fuller wrote:
> 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
> 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").
I think I'm beginning to understand the confusion. You're using runmode
combined with pathinfo differently than we are.
Runmode 'add' would be a submission, not something expected to display a
So, if the asset was 'person', then a pathinfo of /person/add is a
submission of personal data to be added to the db.
If the pathinfo is /person/delete, then it's a delete.
And we have /person defaulting to /person/display, which displays a
Likewise, if the asset was org(anization) [saves typing], then
o /org i.e. /org/display
should be obvious, by analogy with /person.
Consequently, there will never be something like add_submit or
add_display as a runmode.
I tried to explain this in my article on restful pathinfos .
Some people disagree with my approach, but then I'm just learning about
these matters, so my understanding is far from perfect. I've been
directed to this article  to broaden my knowledge, although the
article is a strange mish-mash of good ideas and fuzzy thinking, in that
the author jumps baselessly from topic to topic.
> 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,
Again, this is quite different from how I understand these matters.
I have a base controller App::Office::Contacts::Controller, so my
asset-specific controllers will be *::Person and *::Organization.
The base one has a runmode of display, and the latter 2 each implement
add and delete (and as many other runmode as is necessary, of course).
> > 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.
CGI::App::Dispatch is designed to convert /asset/report/lost_assets into
*::Asset, runmode report, and report_type (say) into lost_assets, by the
way you define it's dispatch table.
Hence there's a perfect correlation between the structure of the
pathinfo and the structure of the code.
That's what I used in App::Office::Contacts . See the synopsis.
ron at savage.net.au
More information about the cgiapp