Good Style for Small Apps

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

Replies are listed 'Best First'.
Re: Good Style for Small Apps by aaron_baugher (Curate) on Jun 22, 2015 at 17:57 UTC
You don't mention how these scripts are run, which makes a difference. The preferred style has changed somewhat over the years. When everything was CGI, people tended to use a small script for each function (though that was by no means universal). Early CGIs tended to have all the HTML right there in the script, which was pretty ugly no matter how you did it, so keeping them small helped keep them cleaner. And running each function (add, delete, etc.) through a different URL to a different script often made sense. Also, since (in most cases) each script was compiled and run every time the script was hit, you didn't want to load a bunch of modules and code that wasn't needed for the particular function being requested. Now that people are using more frameworks and templating systems that keep the layout separate from the code, it's more common to put all code in one file divided up into subroutines. You can still have different URLs, but routed to different subs in one file. The layout code, like HTML, CSS, and Javascript, is in other files. In some frameworks like Catalyst, even code on the other end, like SQL calls, may be in a separate file. So the code stays cleaner. With frameworks and backends like plack, the scripts also tend to be compiled and held in memory, so you don't have to worry about keeping scripts small and light for faster loading. It makes more sense now to get everything loaded at the start so it's ready. It's still possible to break your code up into multiple files for organizational reasons, just not as necessary as it used to be. Without seeing your code, I'd probably say if it's not broke don't fix it, unless you're wanting to move to a different approach altogether, like going from plain CGIs to a framework like Dancer. In that case, you might ask specifically how people who use the new method tend to organize things. Aaron B. Available for small or large Perl jobs and *nix system administration; see my home node.	[reply]
Re^2: Good Style for Small Apps by Hermano23 (Beadle) on Jun 22, 2015 at 18:05 UTC
Thanks for the detailed reply, I definitely made the application closer to your first example than the second, so more than likely I'll keep its current system. We have some new people starting, so I want to make sure that my earlier projects aren't so awful as to be off-putting.	[reply]
Re: Good Style for Small Apps by superfrink (Curate) on Jun 22, 2015 at 17:51 UTC
Instead of multiple scripts to add, remove, update records generally I would write one script that uses command line arguments (eg: Getopt::Long) and a "dispatch table". eg: `sub add { print "added\n"; } sub remove { print "removed\n"; } my $dt = { 'add' => \&add , 'remove' => \&remove }; my $cmd = "add"; if (defined $dt->{$cmd}) { $dt->{$cmd}(); } else { print "command not found: ", $cmd, "\n"; }` [download]	[reply] [d/l]
Re^2: Good Style for Small Apps by Anonymous Monk on Jun 22, 2015 at 18:00 UTC
Instead of multiple scripts to add, remove, update records generally I would write one script that uses command line arguments (eg: Getopt::Long) and a "dispatch table". eg: Also there are several "dispatchers" on the CPAN of all flavors :) Re: Can anybody tell me how MooX::Cmd is supposed to work?, App::Cmd...	[reply]
Re: Good Style for Small Apps by trippledubs (Deacon) on Jun 22, 2015 at 18:19 UTC
I accept this way: #!/usr/bin/env perl use Mojolicious::Lite; # Documentation browser under "/perldoc" plugin 'PODRenderer'; sub validate { my $input=shift; $input =~ s/\W/_/g; return $input; }; get '/' => sub { my $c = shift; $c->render('index'); }; get '/view/:ticket' => sub { my $c = shift; my $ticket = validate($c->param('ticket')); $c->render( 'ticketing', ticket => $ticket, ); }; app->start; __DATA__ @@ index.html.ep % layout 'default'; % title 'Welcome'; Welcome to the Mojolicious real-time web framework! @@ layouts/default.html.ep <!DOCTYPE html> <html> <head><title><%= title %></title></head> <body><%= content %></body> </html> @@ ticketing.html.ep % layout 'default'; % title 'Ticket Viewing'; <h1>This is where the business happens for <%= $ticket %></h1> [download] ./Ticketing get '/view/12312`asdf`' [Mon Jun 22 13:13:10 2015] [debug] Your secret passphrase needs to be +changed!!! [Mon Jun 22 13:13:10 2015] [debug] GET "/view/12312%60asdf%60". [Mon Jun 22 13:13:10 2015] [debug] Routing to a callback. [Mon Jun 22 13:13:10 2015] [debug] Rendering template "ticketing.html. +ep" from DATA section. [Mon Jun 22 13:13:10 2015] [debug] Rendering template "layouts/default +.html.ep" from DATA section. [Mon Jun 22 13:13:10 2015] [debug] 200 OK (0.011596s, 86.237/s). <!DOCTYPE html> <html> <head><title>Ticket Viewing</title></head> <body> <h1>This is where the business happens for 12312_asdf_</h1 +> </body> </html> [download] Using Mojolicious is a great way to do small web apps. They are well encapsulated and contain the primary functionality like logging, templating, debugging. You start out with one file using `mojo generate lite_app <name>` and everything (webserver, logic, templates) is in one file. Later there are options for growing into a full fledged module and separating into more manageable aspects if needed.	[reply] [d/l] [select]
Re: Good Style for Small Apps ( one script versus many ) by Anonymous Monk on Jun 22, 2015 at 17:51 UTC
web app ...~10 small scripts for the UI to interact with....I'm wondering if a single script would be viewed as the clearer approach... I already have a couple of modules with major functions in them, but for execution what would you monks recommend, a larger script with control statements or several smaller scripts like I'm using now? The "web app" deals with urls not scripts, so to the web app , its all the same one script per url is pretty common organizational scheme , script as an API but to a human moving an app from one machine to another, one script to update versus ten scripts to update ... shared config file ... it is all about the same :) But to a human writing a test suite, APIs are the natural choice, but scripts aren't an obstacle, just one step and a few mouse clicks removed, an extra fork/system call so, most of the modern web apps, mojo/dancer2/... favor one script that loads modules that register path/url handlers .... because programmers write subs and put them in modules and call it an API, that is the basic organizational structure for programmers	[reply]
Re: Good Style for Small Apps by sundialsvc4 (Abbot) on Jun 22, 2015 at 18:04 UTC
There are, of course, many pragmatic ways to look at this, and in all cases I would encourage you (first of all) to “be pragmatic.” “You created an issue-tracking application that, I presume, has been reliably in-service for the last two years ... congratulations!” Could you have done it differently? Of course you could. But, you did it, and that’s always the first hurdle. Any locker-room analysis that may take place at this point will be from the proper point-of-view: “how did we win?” These days, most applications of this nature are built using some sort of “framework,” which captures “a wide swath of possible URLs,” parses them according to some set of rules, and uses this to dispatch the response to one of several subroutines within the umbrella of a single Perl module. Templates are used to create the actual HTTP responses, and the framework may or may not stipulate what the implementation of the buttons, hyperlinks, and so-on within the displayed HTML “ought” to be. (And, implementors may or may not follow those rules!) Basically, I would suggest that you should ... first of all, “go ahead and rest on your laurels.” I would not in any way disturb the application that you deployed, and I would neither praise nor apologize for it. In the future, you might well wish to consider the paths that have been blazed by other frameworks (and in many programming languages). One of the very-clear objectives of these frameworks’ designs is the desire to consolidate functional code. If you canvass your “10 small scripts,” you will likely find that they have a not-insignificant amount of source-code and functionality between them ... unless you `use` common modules in all of them. As you contemplate your next Successful Project, consider how you might now approach it within the auspices of a framework, Perl or otherwise. But, “style, et al, always is relative.” I do not believe that there are any absolutes. Every project is different.


"be consistent"
	PerlMonks