Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Good Style for Small Apps

by Hermano23 (Beadle)
on Jun 22, 2015 at 16:43 UTC ( #1131492=perlquestion: print w/replies, xml ) Need Help??
Hermano23 has asked for the wisdom of the Perl Monks concerning the following question:

Hello again, I was wondering if there was an "accepted" style for what I'm doing here. I have a web app that is tracking issue tickets that I wrote about two years ago. I've been looking at it and am pretty unhappy with some of the decisions I made.

One of these decisions was to use ~10 small scripts for the UI to interact with. Things like adding, deleting, changing order, and informing users of changes each have a separate small script that is run on clicking a button or link. This made sense to me, in a C++ sort of way, but now I'm wondering if a single script would be viewed as the clearer approach. I suppose this is more of a software design question, but I'm having a tough time finding clear Perl style guidelines for this dilemma. 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?

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.

      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.
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"; }
Re: Good Style for Small Apps
by trippledubs (Chaplain) 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>
    ./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>
    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.
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

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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1131492]
Approved by Corion
Front-paged by ww
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2018-04-21 08:03 GMT
Find Nodes?
    Voting Booth?