RE: [cgiapp] Number of rm's best practice (more)

[suppressed]

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
> suppressed
> Phone: 212-684-6161
> Fax: 212-684-6226
>
>
> ---------------------------------------------------------------------
> Web Archive:  http://www.mail-archive.com/suppressed/
>               http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
> To unsubscribe, e-mail: suppressed
> For additional commands, e-mail: suppressed
>
>
>


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed