[Update] I should have mentioned that the elapsed time was only about 15 min; maybe less.
I’m a perl programmer from way back and while it has been 2 years since I’ve written any perl of consequence I’ve decided that my client’s application was going to be implemented in perl… just for the fun of it. (I’ve been writing a lot of python+tornadoweb+redis+mongodb and I’m very comfortable in this space. Mojolicious is a half step outside my comfort zone because I really do not want to rewrite this app in python if I don’t have to. I’m a big believer in DRY)
I’m certain that everything is installed. I used the same installation for documentation’s sake recently:
wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.0.0.tgz # need to untar and then relocate the files to the path # MOJOLICIOUS - (as root) curl -L cpanmin.us | perl - App:cpanminus curl -L cpanmin.us | perl - Mojolicious curl -L cpanmin.us | perl - Redis curl -L cpanmin.us | perl - ZeroMQ curl -L cpanmin.us | perl - JSON curl -L cpanmin.us | perl - MongoDB
And we should be ready for the first app.
The application folder structure is going to look like this:
. |-- COPYRIGHT |-- INSTALL |-- LICENSE |-- README |-- bin |-- data |-- doc |-- src `-- test
It’s far from perfect and it’s missing the Mojolicious application (webapp). So let’s create a mojo app (adapted from the docs):
Nope, not yet. First you have to know whether you are going to create a lite_app or a full-blown app.
mojo generate lite_app
mojo generate app
The difference is quite extensive. The second selection is probably best suited for anything more that a a few dynamic pages. And the lite app seems suited for all-in-one file deployment. Right now I’m not sure which is best for this design problem, however, I know that I can convert later; I can cut-paste everything and with any luck I won’t be repeating myself.
So before I make that decision. What does my application look like.
- I need a login screen and session state so that the data is private for my client. One user is sufficient.
- I need to upload a CSV file to a file system and queue that file for processing.
- I need a background process that looks for queued files and then processes them.
- The process is as simple as a GET against a URL, storing the result in another CSV and then getting the next record from the input file.
- Once all of the records have been processed the second file is converted to a PDF of mailing labels.
- The PDF can be downloaded from inventory.
- and finally the user should be able to delete the PDF, the original CSV and the intermediate CSV.
So that’s pretty simple. I need a few pages:
- queue status
- are you sure (popup??)
- completed (optional, could always be inline)
So for the time being lite_app it is. This is what I did:
mkdir webapp cd webapp mojo generate lite_app lisapp.pl
Notice that I specified my application name (lisapp.pl). Starting the app was a breeze eve though it bugs me that the mojo team misused daemon and does not even want to be open minded about it. Oh well, it’s a good platform in spite of ‘daemon’. And then I noticed the output:
$ ./lisapp.pl daemon [Wed Sep 21 00:13:47 2011] [info] Server listening (http://*:3000) Server available at http://127.0.0.1:3000.
Notice that the output is stating that it’s listening on ‘*’ and 127.0.0.1. What’s up with that? When I did a ‘netstat -ln’ I only had one instance of port 3000.
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN
I’m not certain I understand the motives here. But I have to say that it drop be nuts because I knew that I had to test on 0.0.0.0 since my server is at Rackspace. And at first glance I only saw the 127.0.0.1. So it’s on me to pay attention and on them to be more clear.
When I pointed my browser to the URL it popped. As I expected since this is a very lightweight app. So for now I will take a break. Next time I will add the login screen. It’s part of the 3rd screencast and pretty simple. I also need to read-up on the under command. It seems to be where all the power comes from. Keep in mind that the home page is going to be a login screen. No data should leak out. Everyone logs in.