Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Create a web-app with Cgi Appplication
1. How to create a simple Web application with CGI::Application Template::Toolkit and DBIx::Class Leonard Miller February 7, 2009
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
Notas do Editor
First off, who is this talk for? A few years ago I had a conversation with a co-worker who was a competent programmer, with a degree in computer science. In all of his classes, he had never heard of MVC, and found my group’s method of programming to be confusing. He knew Perl, among other languages, so I decided to write this talk for perl programmers who don’t know MVC. Programmers who need to write web applications in their day to day work. Not necessarily heavy perl programmers, and they don’t necessarily have full access to the (machines/apache configs) their scripts are running on, therefore Catalyst is out of the question. As I said my coworker a few years back was an experienced programmer, he just didn’t know exactly what MVC meant, nor does he use Perl a lot. He understood Data how structures work, as well as databases and the complications that arise when using a database. Just not the in’s and out’s of a web app in perl My co-worker also knew about CPAN and knew how to leverage CPAN modules. He just didn’t know about these modules. Also this talk is for me nine years ago. I was a new programmer and didn’t know to separate the code into the MVC components.
Each of the modules can be used and tested alone, you are not required to commit to all three at once. You could do a rolling implementation where you pick one, say Template toolkit, and move to it one page at a time. This way you can test each little piece, and you could switch over the course of a year, each time you do a bug fix on a specific page, you can start to use TT on that page. Also, by themselves, each module is easy to understand. This doesn’t mean that we are tied to these three modules to accomplish these goals, I gave a version of this talk at YAPC08 where instead of DBIx::Class I used the outdated Class::DBI . If you are really tied to a specific ORM like Dave Rolsky’s FEY that you will hear about later today, you can use that instead. The point of this talk is to show one way to implement MVC
Catalyst is a great framework, but Catalyst is too big and not easily available on the systems that my employer uses, but it is easy for us to download and install these modules into a local directory without any elevated access, or access to the apache config files.
The model is the Database. If you have special database needs, or wanted to write your own SQL, that code would go into your Model section. If you were using a completely different database system besides SQL, that would go here. Its like saying: I don’t care how, just get the user with this Primary Key The View is for all the viewing of the data. If you are going to write HTML, that would go into the View. Outside of the Web Application World, the view is the User interface, and all that would go with the UI belongs here. The controller is the glue that takes information from the View, decides what to do with it, processes it, does inserts/deletes/reads/updates as required with the database, and then tells the VIEW what to do. This is where all the business logic belongs, doing things like data validation, and applying business rules
Who has seen code like this? While this isn’t “bad” code, it could be a lot better. Notice on the bottom we have HTML printing out in the while loop. While this code isn’t so bad, you can see where this is going. This is only one slide, and an html error would be very difficult to find once given enough “code rot”
Here I have pointed out that in addition to the Perl you have SQL, HTTP headers, and HTML. MVC here would move each of those into their own modules.
Here is another example of some code that isn’t bad, but can get messy quickly. Here we are explicitly looking to see if a user has filled out a form,with a “first name” and branching on that. Also there is sql mixed into the perl, but the html is abstracted away, which is good,
However submission_form() might have sql embedded in it, and if there is an HTML error it is still hard to find. MVC here would again break the HTML out into its own file, as well as the SQL. CGI::Application also handles the problem of “what function do I call” by having explicit run modes, using an html input field of ‘rm’
Do we have any questions regarding MVC
I am going to create a simple CGI::Application, there are six files that I will need to create my webapp. The .cgi file will contain config info, and will kick off the Controller. The Controller is HelloWorldCgiApp.pm The View files will be TemplateToolkit html files The Model is MyDatabase.pm
Here is the most basic helloworld.cgi you can get. We use the lib, create the object, and then run the object.
This is a little more advanced in that this cgi is passing a few configuration variables to the application Module. Here I am basically setting up a config hash to pass to template toolkit that will prepend and postpend the two given files. I am also passing in a famous string.
By treating the .cgi file as a config file, you make it very easy to setup test scripts/environments. Just put all the production specific information in this file and replace it with the test info including a change to @inc; My office has taken to adding a production flag to the .cgi scripts so that things like overridding of email addresses for testing doesn’t need to be taken out before migrating the code to production.
This here is the setup for your basic Controller module. Here we are calling run modes with two modes, mode 1 and mode 2, and they call the functions start() and sec_page() respectively. The next line, we are deciding what runmode to default to, if no runmode is given.
Runmodes are key to understanding how CGI::App work. Cgi::app looks for a query parameter named ‘rm’ and calls the corresponding function in the hash here. You can set a hidden variable in your html that will determine the next runmode.
This is start() the default runmode that we created in the previous slide. As you can see, we initialize some variables, and then call tt->process() to get the HTML, and we return that. At this point the CGI::App module will take the HTML and send it to the browser along with the HTML headers.
If there is anything you need to do before executing any runmode, there is a prerun that will allow you do do things like creating a database handle, or doing some standard logging.
Now we have moved onto MODEL. This is the Database table that we are using. We have four fields, the first is an autonumber, and a primary key.
Here is the ClassDBI file to interface with the database.
Here is the DBIx::Class file to interface with the database. DBIx::Class also allows One to many relationships to be represented but that is beyond the scope of building a simple web app.
This is how you use DBIx::Class inside the Controller. You call a retrieve, and then pass the documents to Template toolkit.
Here is the basic insert syntax for DBIx::Class
There are some things that you still need to do that might be offered for free from a heavier MVC like catalyst. Because this is a lite framework you still need to explicitly open your database, and manually do inserts/updates/deletes. When you trade off a large framework for a smaller light framework you need to make compromises.
TT is the View component in our MVC framework. I chose TT for my example because that is what my office uses. Yes you can use HTML::Toolkit or just about any other type of templating system. I chose TT for my presentation here. These files are much simpler for folks like Web designers to manipulate and give back to you. Again this is the strength of MVC: your web person doesn’t need to understand how the file interacts with perl, they just need to make the html.
This will print an HTML page with just the scalar var_name printed out. Pretty simple
Here we have a for loop iterating over a list of users.
Here we are using the hash notation. TT is smart because it figures out if it needs to dereference something for you, so you don’t have to. If your code required an arrow to dereference the variable, your html gurus don’t need to worry about any of that with TT.
Here we have an array of users
There are a lot more modules available on CPAN for CGI::Application here are a few
![Who is this talk for? ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)