Django vs. CakePHP vs. CodeIgniter part 1 : downloading – planting the framework tree

I’m studying and comparing web frameworks (Django for Python and CakePHP and CodeIgniter for PHP). This series of posts describes what I learn from it.

Logos of web frameworks: Django, CakePHP, CodeIgniter

http://www.djangoproject.com/ | http://cakephp.org/ | http://codeigniter.com/

In part 1, I’ll be writing about tutorials and initial installation steps. Tutorials are extremely helpful – they let you experience something before going on to read tons of documentation about it, which saves you much time and also helps you avoid getting confused and discouraged right away. Installation tends to be easy, and Django doesn’t even require you to have a web server installed in order to try it. Mostly it’s about downloading, unpacking, a little configuration, and then doing what you want.

I won’t be describing the whole installation process in this post. Instead I’ll focus on downloading, unpacking and understanding what you see when you do that. That means I’ll be helping frameworks move into their new homes on my computer, and see the directories they live in, and find out how they organize their tree-shaped directory structures. Anyway, in this blog post we’ll be learning about why playing with tutorials before (or while) reading the manual can be motivating, about frameworks’ folder structures, document root folders, and about how easy it is to try out a web framework.

P.S. Check out my new CodeIgniter themed blog post about Objects in frameworks – those who get the work done . Object interaction, creating custom classes/libraries, extending the CodeIgniter super object. Study/work notes, basically.

Organizing your code and your coding, or better yet helping you organize them, is a fundamental aspect of frameworks. You might say – but I already do that. But if everyone has their own way of organizing, things get confusing. Having a standardized pattern makes it easier for different teams and coders to communicate and speak the same language. That way you can expect certain pieces of code to always go into certain places in a certain way, other coders can expect that of you without having to negotiate everything every time. I’m not saying it’s the only way to do things, I’m just saying it has made me curious enough to take a look. Another idea that gets mentioned is the DRY – don’t repeat yourself principle. Easier said then done, like anything else.

THE SERVER THING (TRYING DJANGO DOESN’T REQUIRE ONE!)

Taking a look at one of these frameworks is quick and easy if you have a working web server. When I say server I don’t mean a big special dedicated machine accessible from the whole Internet. Web server is just a program that you can install on anything – your own machine, a virtual machine, another machine your computer can reach. Of course, be careful if the particular machine is exposed to the Internet directly. If all that sounds complicated, the good news is that for trying out Django you don’t even need a previously installed web server of any kind. Because Django contains a web server you can play with (not to be used for production, of course).

TUTORIALS – PLAY FIRST, STUDY LATER, AS ALWAYS

It could be a good idea to install a framework and take a look. Django and CakePHP both have nice tutorials to get you acquainted with the basic concepts, especially Django. It can really be fun and encouraging to set up a basic application quickly, and also helps you get into the frame of mind and used to the basic terminology. Starting out just reading lots of theory about something can be frustrating. The manuals still need to be read, but they are much easier to read once you get to play with the subject matter first.

Django tutorial can be found here, and it explains how to create a poll application to experiment with. And each poll has choices associated with it. What I mean by that is, that I appreciated the fact that this basic hello world tutorial makes you create not one but two related tables – polls and choices, related through a foreign key, so you can see how easy it is to get all choices belonging to a certain poll (the thing you might have done in the past with join queries). I’m not saying this because I dread join queries, but because relating tables is a key functionality, so it’s useful to know the Django approach right away. Keep in mind nothing prevents you from writing your own SQL queries, if you prefer.

I wonder what it would be like to know nothing about SQL (Structured Query Language) and relational databases before trying out a web framework. If anyone has actual experience of that, please let me know! I’m wondering if it hurts your learning, since you are skipping steps, or you can also start playing with frameworks and databases mapped for you into objects right away, and then get interested and look behind the scenes later, rather then just start with a whole bunch of database theory right away. But I’ll get to databases, mapping and models in later posts. CodeIgniter does, however, appear to be slightly less “automagical” when it comes to querying, I’ll look into that.

CakePHP offers a simple blog tutorial here. You’ll create a blog, and even get to create, delete and edit posts, but since they didn’t think to make you add comments for example, or tags, or something, you will be created only one table and no relations. Other then that, it’s a nice tutorial. And it might be nice to play with data validation the CakePHP way.

I’ve found that finding CodeIgniter tutorials is not as easy as it should be. From the main page, you do get a link to video tutorials (which didn’t work for me – kept freezing, and I had to use a Firefox plug-in to try and download them, managed with the first, abandoned the second after a few attempts). Luckily, the video tutorial page offers two additional links for tutorials, one of which is this extensive list of video and text tutorials. Personally I find it kind of confusing not to have one simple official text tutorial to rely on (if there is one and I’ve missed it let me know), but there’s nothing I can do about it. I’ve found this Devshed tutorial useful, although it’s very hello world, it only helps you set up the basic framework, no poll app or blog or anything like that. If you speak Italian, there is this simple basic three part tutorial. I used other tutorials, but don’t know which is better. If you have any suggestions, write in the comments, and I’ll add it here. Something like the Django or CakePHP official tutorials (making a basic blog would be nice). Thank you in advance.

PLANTING THE FRAMEWORK TREE

The idea behind installing a web framework is simple – download, unpack, maybe run an installation command (for Django), and then play. Download here: Django, CakePHP, CodeIgniter. Where do you unpack/unzip/untar what you’ve downloaded? For Django files live anywhere outside the root directory* from the start (as we said, without a web server the root directory doesn’t even have to exist). CakePHP and CodeIgniter can be temporarily parked inside the root directory if you’re just playing with it and your computer is not exposed to the Internet. But that’s a long story.

And what’s this Django installing all about? You just use the command ‘sudo python setup.py install‘ for Linux and ‘setup.py install’ for Windows, and that copies some useful Django files somewhere where Python knows how to find them. Where is that? The site-packages directory. What’s that? It’s a directory where modules live. It’s location depends on the operating system, and there are several ways to find it. For example, you can simply use this command to find your site-packages directory:

python -c “from distutils.sysconfig import get_python_lib; print get_python_lib()”

The idea is that Django becomes one of your Python modules and Python knows where to look for it because it will be inside the PYTHONPATH. Python path is Python’s list of where it keeps things (to see the path, including the location of the site-packages folder, type python and press enter to get the Python interactive shell, then type import sys and press enter, then sys.path and press enter).  PYTHON PATH is an environment variable. But enough about that for now.

A note about document root directories. The root directory is the part of a web server that gets seen from the Internet. For example, if I visit http://www.example.com on a server that would take me to its document root directory, which might be  ‘/var/www/html/’ (I won’t necessarily see the list of all files in the directory, though), and http://www.example.com/subdirectory would take me to a subdirectory of that directory. Django is the only one of these three frameworks that never steps foot in the document root. This opens up the whole topic of the relationship between the Apache or another real web server and the framework, but I won’t be getting into it right now. The bottom line is – you should be careful about what you keep inside your document root directory. For example, if the server is overloaded with requests it can start serving raw PHP files, if they are in the document root. You can later improve things with doing an advanced installation of CakePHPor by moving CodeIgniter files somewhere else on the server, to move the files elsewhere.

What is this talk about modules and libraries? Even the simplest dynamic website is still a basic web application. Since it would be silly to rewrite every piece of functionality for every application, programmers reuse pieces of application and these are called libraries, modules etc. These are all kept somewhere on the computer where different applications know how to find them and can reach them. Frameworks are in part a skeleton for you to put you code in, and in part libraries. Django always moves the libraries into their right place right away, while for CakePHP and CodeIgniter you only do that for an advanced installation I mentioned above.

The “skeleton” part of a framework folder structure is interesting. It will determine where you put code and how you organize code. CakePHP and CodeIgniter use the MVC (Model View Controller) pattern, where the model handles the basic behavior and data of the application, the view outputs the data and creates the interface, and the controller controls the input and the output and what happens in between – it tells the other two what to do. For each of these there is a directory. Django uses something they call the MTV approach. No controllers at all. Basically it’s up to the view to organize everything on its own, with a little help from the model. CodeIgniter looks very precise when it comes to its MVC pattern, at least that’s my first impression. Only the model talks to the database, that is, the model contains functions which query the database, and the the controller uses those and sends data to the view. In Django, there is no controller and anyone can query the database any time. In CakePHP, the pattern is MVC, but the database is really queried from the controller. But then again, I’m no MVC expert. Now let’s see what the directory structure teaches us.

For CakePHP, after “installing”/unpacking it, the directory structure is:

[user@host cake_1_3]$ tree -L 1
.
|– README
|– app <— our application ‘skeleton’
|– cake <— the CakePHP libraries
|– index.php
|– plugins
`– vendors

4 directories, 3 files

You can’t see the .htaccess file because its hidden, because I’ve canceled it (for now), and because it’s a long story. Scratch that, let’s pretend I didn’t mention it for now. Anyway cake libraries files are in there, in their own directory, not elsewhere (that can be changed). The app directory is interesting, because it contains the Model View Controller structure:

[user@host cake_1_3]$ tree -L 1 app/
app/
|– config
|– controllers
|– index.php
|– libs
|– locale
|– models
|– plugins
|– tests
|– tmp
|– vendors
|– views
`– webroot

For CodeIgniter, after “installing”/unpacking it, the directory structure is:

4 directories, 3 files

[user@host CodeIgniter_1_7]$ tree -L 1 system/
system/
|– application <— our application ‘skeleton’
|– cache
|– codeigniter <— the CodeIgniter libraries
|– database
|– fonts
|– helpers
|– index.html
|– language
|– libraries
|– logs
|– plugins
`– scaffolding

11 directories, 1 file

As before, we are interested in the application folder:

[user@host CodeIgniter_1_7]$ tree -L 1 system/application/
system/application/
|– config
|– controllers
|– errors
|– helpers
|– hooks
|– index.html
|– language
|– libraries
|– models
`– views

The MVC pattern is clear, and other details will be explained as I learn more about every single aspect of this structure.

The Django tree grows as you do things. There is a handy command line tool which you use to “plant” new branches on your Django tree (CakePHP has one too which is called bake, but they are different). First you create a project, which is a Python representation of your website. A project entitled ‘mysite’ looks like this:

mysite/
__init__.py
manage.py
settings.py
urls.py

Very briefly, settings.py is for settings, urls.py is for making sure your Django does the right thing when the user types in the right URL, manage.py is another very nice command line tool for interacting with Django, and __init__.py is just an empty file that signifies that directory is a Python package. Then you create an app. Apps add different functionalities to your website. You can understand that really quickly in this great Django tutorial. These example “trees” are taken from there. And when you create an app called ‘polls’ inside your ‘mysite’ project, it will look like this:

polls/
__init__.py
models.py
tests.py
views.py

You can see models and views (files, not folders), and no controller. Since CakePHP and CodeIgniter don’t divide site functionalities into apps, they have folders where all different model files go, and the same for views and controllers. Django has, for each app, a models.py where you map your data so Django can create databases and let you access them as objects, and views.py for defining how Django presents the results to the user’s browser.

FROM SPOT-THE-DIFFERENCE TO BEHIND-THE-SCENES TINKERING

If we were to follow the walk-before-you-can-run and one-step-at-the-time logic, it would be advisable to start making dynamic websites from scratch before learning frameworks at all. Luckily, I have some experience with that, so I didn’t just grab a framework out of nothing. I noticed an interesting thing, though. Examining three frameworks at once had some effects similar to those of coding from scratch – by noticing how each system does things in its own way made me ask myself “why” quite a few times, made me understand the logic and the mechanisms much better. It’s not just painting by numbers. I haven’t yet tinkered that much with the behind-the-scenes inner workings of frameworks, but I certainly intend to, and will blog about it later on.

BLOGGING IS MORE DIFFICULT THEN CODING

Writing this post was more difficult for me then coding and studying frameworks. I hope reading it wasn’t even more difficult for you then it was for me to write it.  For one thing, I’m aware that this post looks way too long. I have a feeling that I have made a whole bunch of errors, but if I keep rereading it I will become more of an apprentice blogger then apprentice coder. Blogging is useful, however. Having to write about things I become more aware of what I need to understand better, and putting it all in my own words makes it more mine and easier to comprehend. And it’s also a we(b)log I can go back to. I know this post is not a proper tutorial. Writing it makes me appreciate the people who write tutorials and be thankful for all the effort they put to be concise and explain things well. I hope these posts help me improve so that one day I can write proper tutorials. I am also confused about what kind of a reader I should write for – how much does the reader know already? What do you think? Thank you for your patience and for any comments, be gentle when you criticize, I’m still learning.

THE WHOLE SERIES, SO FAR:

0) No More Static Web Sites (learning from mistakes #1)
1) part 1 : downloading – planting the framework tree
2) part 2: how does the server talk to the framework?
3) Django, CakePHP and Codeigniter, part 3: Models, data, relationships and foreign keys4) Django, CakePHP and CodeIgniter, part 4: the Model-View-Controller or Model-Template-View interactions
5) Objects in frameworks – those who get the work done – CodeIgniter notes

<< No More Static Web Sites (learning from mistakes #1)

Advertisements

About apprenticecoder

My blog is about me learning to program, and trying to narrate it in interesting ways. I love to learn and to learn through creativity. For example I like computers, but even more I like to see what computers can do for people. That's why I find web programming and scripting especially exciting. I was born in Split, Croatia, went to college in Bologna, Italy and now live in Milan. I like reading, especially non-fiction (lately). I'd like to read more poetry. I find architecture inspiring. Museums as well. Some more then others. Interfaces. Lifestyle magazines with interesting points of view. Semantic web. Strolls in nature. The sea.
This entry was posted in frameworks, tutorials and tagged , , , , . Bookmark the permalink.

10 Responses to Django vs. CakePHP vs. CodeIgniter part 1 : downloading – planting the framework tree

  1. luglio7 says:

    Good work man, hope your choice is for cakephp 😉

  2. daBayrus says:

    i started using CodeIgniter when it was still in v1.6.2 .. now that v.2.0.0 is now officially released, i have upgraded my latest project with that version.. im also using modified version of the loader and controller so i could use haml.. lots of fun..

  3. Michael Duddles says:

    Excellent comparison, ApprenticeCoder! Thank you for posting this – you practically read my mind as to exactly what has been weighing on me over the last few days. Very elucidating, friend.

  4. Biggie Smalls says:

    Good work man girl

  5. nice blog… 🙂 i like the way you say – TUTORIALS – PLAY FIRST, STUDY LATER, AS ALWAYS…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s