Re: [cgiapp] CGI::App Developing Runmodes Structure
I believe your right Ron/Mark, I'm thinking of run modes in the way I used
to build webpages. (with a dispatcher subroutine eg. sub main { if ($rm eq
"foo") { #run foo sub} elsif ($rm eq "bar") { #run bar sub } } )
So as the be all and end of what state I should be in and what the app needs
to do.
Right now I'm just trying to build a skeleton of my project just to see how
I would control movement from page to page hopefully this will start to give
me a better understanding of C:A. I must admit though I'm still struggling
to not treat run modes as described, if I only have for example "edit" and
not "edit_display", "edit_update", "edit_ajax" then I need another variable
and dispatch code to figure out what this edit submission should still be
doing. After reading more on C:A::Dispatcher it seems like it might be the
happy medium between overloaded run modes and run modes gone wild.
I was not familiar with this REST term I will read up on it some more, it
seems as though this is what C:A::Dispatcher uses.
I took a look at the App::Office Contacts.pm, Collector.pm and Base.pm but
couldn't find how things were dispatched could you point me to the right
area to look for how you did it.
Thanks
John
-Original Message-
From: cgiapp-boun...@lists.erlbaum.net
[mailto:cgiapp-boun...@lists.erlbaum.net] On Behalf Of Ron Savage
Sent: Sunday, April 04, 2010 7:43 PM
To: CGI Application
Subject: Re: [cgiapp] CGI::App Developing Runmodes Structure
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
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 car
Re: [cgiapp] CGI::App Developing Runmodes Structure
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 > 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/ ## ####
Re: [cgiapp] CGI::App Developing Runmodes Structure
On Sat, Apr 3, 2010 at 9:30 PM, John Cianfarani 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 # 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/ ## ####
Re: [cgiapp] CGI::App Developing Runmodes Structure
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-boun...@lists.erlbaum.net [mailto:cgiapp-boun...@lists.erlbaum.net] 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 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://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # 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/ ## ####
Re: [cgiapp] CGI::App Developing Runmodes Structure
On Sat, Apr 3, 2010 at 1:43 PM, John Cianfarani 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://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
