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

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).

Jacob Kaplan-Moss of Django at Google Tech Talks 2008

[Links to watch the Google Tech Talks by Jacob Kaplan-Moss (his web site)of Django: 2006, 2008]

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.

In reality, I was confused about the whole static web site thing from the start. I have a background in PHP programming, so now that I’m coming back to that, and as I was waiting to find a job in a web agency, I thought I’d freelance a little. And was asked to do a little website all on my own. I used to write the back-end and basically just serve XML to others who developed the interface, so I wasn’t used to the client (browser) side of things, but it was interesting to learn. I also took up JavaScript and that was fun and useful since I could play with asynchronous programming and the HTTP requests and responses.

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.

Django:

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).

CakePHP:

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

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

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 learn-from-mistakes, musings and tagged , , , , , , , , . Bookmark the permalink.

4 Responses to No More Static Web Sites (learning from mistakes #1)

  1. claudio brandolino says:

    Hi. You probably took a look at it already, but I suggest you reconsider CodeIgniter as a PHP framework.

    Apart from being smaller, CodeIgniter has the great advantage of being simple without being magic – I mean, magic is great and RoR is fun, but a framework that eases your work to the point of making it difficult for you to understand how – for instance – the connections between models are handled when you do such great tricks as


    $this->Post->Comment->findByPostId($id);

    isn’t imho the best framework to learn with.

    Plus, docs are really great and there is a huge choice of video tutorials providing solutions for real-life problems: check ’em out here.

  2. Thanks for your comment!
    CodeIgniter is definitely on my interesting frameworks list. I can see your point, makes sense. I’ll think about it.

    • daBayrus says:

      Try CodeIgniter.. I’ve been using the framework for more than two years now and my codes are getting shorter the more I use it.. 🙂

      • Thank you for your comment. I’m doing an experiment right now – making the same small toy website in three versions: Django, CakePHP and CodeIgniter. I’ll be blogging about it, hope I learn useful things.

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