well has asked for the wisdom of the Perl Monks concerning the following question:

Hi All!

My warmest regards to all Monks who take part in a discussion of input switch topic! Yes - CGI::Application is a kind of great module. But how about multi-runmodes: for example 

Class:
  USERS 
Methods:
  add
  del
  list
  ... and so on
Class:
  INVOICES
Methods:
  add
  del
  print
  ... and so on
Class:
  Any other class we can need
Methods:
  Any other methods we can need

In terms of C::A mode_param is a classes and run_modes is a methods of such class

It will be better to pass to C::A mode_param method array instead of scalar.

At this time I use following code for my needs: 

my @isect = ();
my @union = ();
my %union = ();
my %isect = ();
my @possible_states = ('users','sources','publisher','authors','joinus
+','content','logs','genre','sq'); #Objects array
my $e = '';
my @current_state = $main::CGI->param();
foreach $e (@current_state,@possible_states) { $union{$e}++ && $isect{
+$e}++ }
@isect = keys %isect;
my $sub_subst = uc($isect[0]) || displayQueryScreen();
my $what_to_do = $sub_subst->new();
my $action = $main::CGI->param ($isect[0]);

$action =~ s/^_+//; #filtering private methods
$what_to_do->$action() || displayQueryScreen ();

[download]

So, I have predefined array of accessible classes next get array of CGI hash keys and intersect them both (intersection from Perl Cookbook). First object in intersection is needed object and so on.

Question is
1. Can I use 'multi-runmodes' with C::A?
2. Why not to use my code?

Replies are listed 'Best First'.
Re: multi of so called "runmodes"
by valdez (Monsignor) on Sep 11, 2002 at 14:39 UTC

    The first and most common answer to your second question is "why reinvent wheels?". I like to reinvent wheels, but sometimes it is better to spend our time on something more useful.
    There are many other reasons to use CGI::Application:

    • it is possible to subclass and extend C::A; I used this approach to add session handling;
    • it is possible to execute pre-runmodes and change rm at run time
    • you get CGI and HTML::Template objects for free :)
    • there is a nice mailing list where you can post your questions and suggest improvements; online archives are here (old messages are also here)

    I'm sorry, but I didn't understand your first question, so I can't give you an answer.

    Ciao, Valerio

[reply]
Re: multi of so called "runmodes"
by Solo (Deacon) on Sep 11, 2002 at 14:04 UTC
    Jesse Erlbaum the author of C::A hosts a mailing list for the module. Here's an excerpt from the info mail with the goods: 
    To subscribe to the list, send a message to:
   <cgiapp-subscribe@lists.erlbaum.net>

To remove your address from the list, send a message to:
   <cgiapp-unsubscribe@lists.erlbaum.net>

Send mail to the following for info and FAQ for this list:
   <cgiapp-info@lists.erlbaum.net>
   <cgiapp-faq@lists.erlbaum.net>

Similar addresses exist for the digest list:
   <cgiapp-digest-subscribe@lists.erlbaum.net>
   <cgiapp-digest-unsubscribe@lists.erlbaum.net>

To get messages 123 through 145 (a maximum of 100 per request), mail:
   <cgiapp-get.123_145@lists.erlbaum.net>

To get an index with subject and author for messages 123-456 , mail:
   <cgiapp-index.123_456@lists.erlbaum.net>

    [download]
    I couldn't find if there was a web-searchable archive, though.
    --
    May the Source be with you....

    You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

[reply]
[d/l]
Re: multi of so called "runmodes"
by adrianh (Chancellor) on Sep 14, 2002 at 21:53 UTC
    Can I use 'multi-runmodes' with C::A?

    If I'm understanding what you mean by "multi-runmodes" correctly - the answer is no. I would class that as a feature of CGI::Application - it encourages a clear separation of the application logic into a single controller class.

    Why not to use my code?

    Well - if it does what you want nothing at all :-)

    That said, if I saw the following in a code review I would worry and query the author:

    $action =~ s/^_+//; #filtering private methods
$what_to_do->$action() || displayQueryScreen ();

    [download]

    Even though you're renaming method names that start with an "_", running arbitrary methods based on user input is normally considered a "bad" thing.

    While it may be safe with the current classes/methods it puts the burden of doing safe things in the wrong place (the modules rather than the caller).

    If somebody adds a method to a class that could potentially do something dangerous - your CGI application is suddenly unsafe.

    If you had had a list of approved "safe" methods and checked the supplied $action against it your system would not run the dangerous method.

    On a slightly more abstract level you lose a lot of the advantages that CGI::Application gives you (inheritance, reuse, etc.)

    The fact that you need so many classes to implement your application would also worry me. It would suggest that there is another level of abstraction that you need to look for... but I could be wrong :-)

[reply]
[d/l]

Back to Seekers of Perl Wisdom