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 <jcianfar...@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 r...@savage.net.au http://savage.net.au/index.html ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################