I’ve said it to my nephew, I can say it to myself as well: one must learn from one’s mistakes. And in this case my mistake was to think that it makes sense to try to make a static website in 2011. Not only web SITES turning into web APPLICATIONS, but also, as a friend of mine recently explained – no web site these days remains really static for long. The client always wants something to become modifiable, even if its just the news or the offers section. When this happened to the web site I was trying to make static, I thought I was too far along to change my strategy, so I kept most of it static while trying to sneak in some dynamic parts hastily written in PHP. But things got messy, and my idea was not very practical and scalable at all. Plus – why would every coder have to reinvent every wheel every time, for every CRUD (Create, Read, Update and Delete) based application? (Unless the plan is “to learn more about wheels”, as Jeff Atwood suggests in this post on his Coding Horror blog.) So, I’m going to write this post about my entrance into the world of out-of-the-box web frameworks (starting with Django for Python and CakePHP).
BTW How do you deal with this? Templaters? Url handlers? Frameworks? In-house solutions? Static sites? Do you think static web sites make any sense today? Click to keep reading AND/OR tell me what you think in the comments.
But when I started writing HTML, I was baffled by how much repetition I was risking. I obviously wrote separate include files for header and footer, but that wasn’t enough. I kept noticing other similarities between pages of the site. My web site basically consisted of sections and subsections, and all sections had the same form with different content, and subsections were also very similar to sections. So I started dividing the site into slices and using the include strategy on those as well, but more I went along the messier and less appealing it all looked to me. I asked on IRC, and they started suggesting I use an url handler etc. When I asked if that was a bit too much for a static site like that, they even made a snark remark that if I don’t want answers like that I “shouldn’t ask coders”. So much for that. So I kept my mess.
Until I woke up one day and decided to use a framework. I had already tried that path, but got discouraged. This time I was more determined, plus when I asked for advice from that friend of mine from the first paragraph he also said to use frameworks, which was a nice coincidence. I thought I’d try both Django, a Python platform, and CakePHP. It wasn’t easy to choose. Times have changed. Only several years ago, frameworks weren’t as widely spread and I had participated in writing an in-house platform, providing the PHP framework-like part of it. There was even a Django-like PHPMyAdmin inspired automatic admin interface. But I have changed, and the times have change. Today I want to take things slowly and learn to do them well, instead of letting my imagination run too wild in the code. Plus – frameworks are everywhere. And they are nice.
Frameworks include the above mentioned URL handler. That is, they intercept the URLs passed through the browser and server to your site, parse them, and decide what to do based on that. So, instead of only having an actual file called myrecipes.html on your site, you have an URL handler that knows what to do when the user asks for myrecipes and what to do when they ask for recipes/75. From that points on it depends on the framework and the pattern it is implementing.
As Jeff Croft puts it in this blog post:
“The best way to describe the MVC concept to the audience of this blog is with an analogy: MVC strives to rectify many of the same problems that the web standards movement tried to solve on the front end of things. Largely, MVC is about the separation of the different layers of a program. Just as the web standards movement was largely about breaking apart the content, presentation, and behavior layers of a web document, MVC is all about a clean break between the data, the logic that occurs around that data when a user interacts with an application, and the presentation of that data to the user. Just like web standards, right? Right.”
CakePHP uses the MVC pattern (model view controller), while Django prefers an approach they call MTV (model template view). Model is the part of your web application/site that handles the information, the contents, the data, and it usually maps the database. When you want to talk to the database, you just consult the model, and it does it for you. Controller controls the interactions – it takes the input, decides to call upon the model, etc. and then it uses the views to display the results. The MTV approach is a little less clean cut, we could say that the content from the model gets shaped in a way defined by the template somewhere along the line, and the view puts it all together and returns the web page (HTTP response) or whatever output (XML like RSS, email, etc.).
Some (not all, onviously) points for Django and CakePHP.
1) Super simple automatic admin back-end panel. Just by uncommenting a few lines, it’s automatically created for you, based on the model (db structure), and even chooses the right input field types for the HTML form based on the field types in the db.
2) Very nice db mapper (object-relational mapper), so you can just create your classes to model your content’s structure, and your database will be organized accordingly. Later you access the data through the objects. I think I’ll be looking into these mappers outside frameworks too, like SQLAlchemy.
3) My favorite beginner’s tutorial ever.
4) Modularity. You can use as much and as little of it as you want. And you can reuse the code (apps), if you write it in a reusable way.
5) Creative authors. My interest in Django increased when I saw this Google Tech Talk where Jacob Kaplan-Moss told the inspiring story about going to work for some creative types at a local newspaper in a small town, and what came out of it. And how Django came to be a great tool for ‘perfectionist with deadlines’ because it served to create ad-hoc apps to make new data that journalists wanted to share understandable to the readers. It’s nice to know that great projects don’t have to come from big and important sounding labs or companies, all it takes is a few creative peoples and interesting problems to inspire them (journalists and readers, in this case, and their real life web app needs).
1) The MVC pattern. Everything in it’s right place. Very neat and orderly.
2) Naming conventions remind me of that old in-house framework I used to work on, only they are less strange, of course. Makes me feel at home.
3) The tutorial is making me write my own SQL statements. This may look like a paradox, since I liked the Django mapper so much, and it is. Mappers are great, but I DO need some SQL practice. So, I’m happy either way. Sort of.
4) The tutorial and the documentation are nice. At the first glance, it looked less clear then Django, but isn’t. And the cute graphics.
5) User input validation mentioned as soon as the tutorial. Let’s hope that works out well.
This make look like I’m favoring Django, but that’s not true at all. I’m still working on this, and may end up preferring either one of those. Back to work, then.
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 keys