Jesse, Thanks for reeling us back in. You pose a great paradigm. I'm liking it. This approach seems to mirror my pre C::A days where I called a different Perl scripts for each function:
<form action="cgi-bin/users.pl"...> or <form action="cgi-bin/widgets.pl"...> So, your newly suggest approach might look like: <form action="cgi-bin/users.cgi"...> or <form action="cgi-bin/widgets.cgi"...> Right? Brad > Hi Richard -- > >> Reading the thread on 'Good practices: how many run modes in >> an app' it >> is obvious my current application under development is going way over >> the 'recommended' upper limit of rm's. I know I need to break it into >> smaller units based around functionality, but how? > > > A better question to start with is: "Why?" > > Reading this thread, it appears that most suggestions are cosmetic fixes > which will superficially move run mode methods out of your main module > and into other modules. This is useful only if your main goal is to > have fewer run modes in one physical file. > > Years ago, when CGI-App was first released, the question of "how many > run modes should my module have?" was posed to me. My answer was to > give the number of run-modes my applications typically have. That > doesn't really answer the "Why separate?" question. > > And what is it you're supposed to be separating, anyway? > > I separate instance scripts -- not run-modes. (The "Instance Script" -- > aka, the *.pl or *.cgi file.) I typically create separate instance > scripts based on a few different "soft" criteria: > > 1. Are the functions provided to the user substantially different? > 2. Do different types of users use these scripts? > 3. Might I want these scripts to be called from different places? > 4. Do these scripts have different "start modes"? > > If a preponderance of the answers to these questions are "yes", then I > create a separate instance script, and a separate module (with separate > run-mode methods). The "Why?" in this case was because I could use the > file and directory orientation of the Apache web server to implement > different security rules, and so that I could create logical, > bookmark-able (email-able) URLs which provide entry points into the > respective applications. > > As you can see, these questions are highly subjective (possibly with the > exception of the last one). As a result, you get very different answers > depending on your point of view. For example, consider the following > admin functions: > > * Manage users > * Manage groups > * View logs > * Manage Widgets > * Manage Orders > > In my way of thinking, these are five separate applications. However, > if you think of them as functions of one big "admin control panel" you > might come to a very different conclusion. > > HTH, > > -Jesse- > > > -- > > Jesse Erlbaum > The Erlbaum Group > [EMAIL PROTECTED] > Phone: 212-684-6161 > Fax: 212-684-6226 > > > --------------------------------------------------------------------- > Web Archive: http://www.mail-archive.com/[email protected]/ > http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
