[cgiapp] CGI::App Developing Runmodes Structure

[Ron Savage]

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

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

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
pre-existing record.

Likewise, if the asset was org(anization) [saves typing], then
o /org/add
o /org/delete
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 [1].

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 [2] 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,
> asset/report?rm=lost_assets

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 [3]. See the synopsis.

[1] http://savage.net.au/Perl-at-work/html/starting2rest.html

[2]
http://duncan-cragg.org/blog/post/strest-service-trampled-rest-will-break-web-20/

[3] http://search.cpan.org/~rsavage/App-Office-Contacts-1.06/


-- 
Ron Savage
ron at savage.net.au
http://savage.net.au/index.html