webdevelopment | Matthew Daly's Bloghttps://matthewdaly.co.uk/blog/categories/webdevelopment/
webdevelopment | I'm a web developer in Norfolk. This is my blog...Sun, 13 Jan 2019 20:21:39 GMThttp://blogs.law.harvard.edu/tech/rssgrunt-blogbuilder https://github.com/matthewbdaly/grunt-blogbuilderMatthew Daly 2019https://matthewdaly.co.uk/blog/2012/12/15/running-the-php-development-server-with-laravel/
https://matthewdaly.co.uk/blog/2012/12/15/running-the-php-development-server-with-laravel/Sat, 15 Dec 2012 00:26:00 GMTOne thing that I’ve really never liked about PHP is the requirement to install a full-blown web server, so I was pleased when PHP 5.4 shipped with a built-in development server. However, it seems like no PHP framework has yet embraced this to the extent that their counterparts for languages like Python have.

I’ve recently decided that CodeIgniter is no longer fulfilling what I need from my main go-to PHP framework, and I’ve been looking at Laravel as a likely replacement. It occurred to me that I could create an Artisan task to run the development server quite easily, and after a little tinkering, I put this together, which worked well:

Once this is in place, you can just run php artisan runserver to run the development server, and hit Ctrl-C to stop it, giving you an experience much like that with Django. Note this requires PHP 5.4 or greater. You also have the option of specifying a different port eg php artisan runserver 7000 for port 7000.

]]>https://matthewdaly.co.uk/blog/2012/11/03/testing-php-web-applications-with-cucumber/
https://matthewdaly.co.uk/blog/2012/11/03/testing-php-web-applications-with-cucumber/Sat, 03 Nov 2012 16:43:00 GMTEver since I first heard of Cucumber, it’s seemed like something I would find really useful. Like many developers, especially those who use PHP regularly, I know full well that I should make a point of writing proper automated tests for my web apps, but invariably wind up just thinking “I haven’t got time to get my head around a testing framework and it’ll take ages to set up, so I’ll just click around and look for bugs”. This does get very, very tedious quite quickly, however.

At work I’ve reached a point with a web app I’m building where I needed to test it extensively to make sure it worked OK. I soon began to get very, very fed up of the repetitive clicking around necessary to test the application, so I began looking around for a solution. I gave Selenium IDE a try, but I found that to be annoyingly unreliable when recording tests. I’d heard of Cucumber, so I did some googling, found some resources, and began tinkering with that. Quite quickly, I had a few basic acceptance tests up and running that were much more reliable than Selenium IDE, and much less tedious to use than manual testing. Within a very short space of time, I realised that Cucumber was one of those tools that was going to dramatically improve my coding experience, much like when I switched from Subversion to Git.

What’s so great about Cucumber compared to other acceptance testing solutions?

Cucumber scenarios are written using Gherkin, a simple syntax that makes it easy for customers to set out exactly what behaviour they want to see. Far from being tedious requirement documents, these set out in a simple and intuitive way what should happen once the application is complete. By requiring customers to think carefully about what they want and get it down in writing, you can ensure the customer has a good idea what they want before you write any code, making it much less likely they’ll turn around afterwards and say “No, that’s not what we want”. This, more than anything, is for me the true power of Cucumber - it allows customers and developers to easily collaborate to set out what the web app will do, and gets you automated tests into the bargain as well.

Because Cucumber is packaged as a Ruby gem, it’s easy to install it and any other Ruby modules it may require.

You can use Capybara to test your web app. Capybara is a very handy Ruby gem that allows you to easily interact with your web app, and it allows several different drivers to be used. If you don’t need JavaScript, for instance, you can use Mechanize for faster tests. If you do, you can use selenium-webdriver to automate the browser instead, and it will load an instance of Firefox and use that for testing.

It can also be used for testing RESTful web services. HTTParty is another handy Ruby gem that can be used for testing an API.

One question you may ask is ‘Why use a Ruby tool to test PHP apps?’. Well, there is Behat, a very similar tool for PHP, so you can use that if you’d prefer. However, I personally have found that it’s not too much of a problem switching context between writing Ruby code for the acceptance tests and PHP code for the application itself. Ruby also has some advantages here - RVM is a very handy tool for running multiple instances of Ruby, and RubyGems makes it easy to install any additional modules you may need. You don’t really need to know much Ruby to use it - this is essentially my first encounter with Ruby barring a few small tutorials, but I haven’t had any significant issues with it. Finally, the Cucumber community seems to be very active, which is always a plus.

When searching for a tutorial on getting Cucumber working with PHP, I only found one good one, and that didn’t cover a lot of the issues I’d have liked to cover, not did it cover actually using Cucumber as part of the development process, so I had to puzzle out much of it myself. So hopefully, by covering more of the ground that your average PHP developer is likely to need, I can show you just how useful Cucumber can be when added to your PHP development toolkit.

In this tutorial, we’ll build a very simple todo-list application using the Slim framework, but we’ll use Cucumber to test it throughout to ensure that it works the way we want it to. Hopefully, by doing this, we’ll get a rock-solid web app that meets our requirements exactly.

First of all, you’ll want to install RVM to make it easier to manage multiple Ruby installs. You may be able to use your system’s Ruby install, but RVM is usually a safer bet:

\curl -L https://get.rvm.io | bash -s stable --ruby

This was sufficient to install RVM on Mac OS X. On Ubuntu, I also had to install the openssl and zlib packages. Before installing RVM, use apt-get to install the required packages:

This makes it easier to get your project set up somewhere else because you can put the Gemfile under version control, making it easier to duplicate this setup elsewhere.

With that out of the way, let’s start work on our app. To save time, we’ll use the Slim framework to do some of the heavy lifting for our application. Download Slim and put it in a folder on your local web server.

Now, before we actually write any code, we’ll set out our first Cucumber scenario. Create a folder inside the folder you put Slim inside and call it features. Inside it, create a new file called todo.feature and put the following content into it:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item
Given I am on the home page
When I click on New Item
And I fill in the item
And I click the button Submit
Then I should see the new item added to the list

Notice how simple this is? Everything is written as an example of how an end user would interact with the site. There’s nothing hard about this - it just describes what the site needs to do.

The first line is just the name of this feature. The following three lines are just a comment. Then the Scenario line gives a name to this particular scenario - a Scenario is just a series of steps that describes an action.

Then, we see the Given line. This sets out the starting conditions. Note that you can easily set out multiple starting conditions using the And keyword on subsequent lines, as we do later in the file. Here, we’re just making sure we’re on the home page.

Next, we see the When line. This, and the subsequent And lines, set out what actions we want to take when going through this step. In this example, we’re clicking on a link marked ‘New Item’, filling in a text input, and clicking the Submit button. So we’re already thinking about how our application is going to work, before we’ve written a line of code.

Finally, we see the Then line. This sets out what should have happened once we’ve finished going through this step. Here we want to make sure the new item has been added to the list.

Now, go to the folder you unpacked Slim into and run cucumber from the shell. You should see something like this:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/todo.feature:8
When I click on New Item # features/todo.feature:9
And I fill in the item # features/todo.feature:10
And I click the button Submit # features/todo.feature:11
Then I should see the new item added to the list # features/todo.feature:12
1 scenario (1 undefined)
5 steps (5 undefined)
0m0.004s
You can implement step definitions for undefined steps with these snippets:
Given /^I am on the home page$/ do
pending # express the regexp above with the code you wish you had
end
When /^I click on New Item$/ do
pending # express the regexp above with the code you wish you had
end
When /^I fill in the item$/ do
pending # express the regexp above with the code you wish you had
end
When /^I click the button Submit$/ do
pending # express the regexp above with the code you wish you had
end
Then /^I should see the new item added to the list$/ do
pending # express the regexp above with the code you wish you had
end
If you want snippets in a different programming language,
just make sure a file with the appropriate file extension
exists where cucumber looks for step definitions.

At this stage, Cucumber isn’t doing anything much, it’s just telling you that these steps haven’t been defined as yet. To define a step, you simply write some Ruby code that expresses that step.

Let’s do that. Under features, create a new directory called step_definitions. Inside that, create a file called todo_steps.rb and paste the code snippets returned by Cucumber into it. Once that has been saved, run cucumber again and you should see something like this:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
TODO (Cucumber::Pending)
./features/step_definitions/todo_steps.rb:2:in `/^I am on the home page$/'
features/todo.feature:8:in `Given I am on the home page'
When I click on New Item # features/step_definitions/todo_steps.rb:5
And I fill in the item # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
1 scenario (1 pending)
5 steps (4 skipped, 1 pending)
0m0.004s

So far, the steps we’ve written don’t actually do anything - each step contains nothing but the pending statement. We need to replace the code inside each of those steps with some Ruby code that implements that step. As the first step in this scenario is still pending, Cucumber skips all the remaining steps.

Let’s implement these steps. First of all, we need to set some configuration options. In the features folder, create a new folder called support, and under that create a new file called env.rb. In there, place the following code:

This includes all of the Ruby gems required for our purposes, and sets Capybara to use the Mechanize driver for testing web apps. If you’ve not heard of it before, Capybara can be thought of as a way of scripting a web browser that supports numerous drivers, some of which are headless and some of which aren’t. Here we’re using Mechanize, which is headless, but later on we’ll use Selenium to show you how it would work with a non-headless web browser.

With that done, the next job is to actually implement the steps. Head back to features/step_definitions/todo_steps.rb and edit it as follows:

Given /^I am on the home page$/ do
visit "http://localhost/~matthewdaly/todo/index.php"
end
When /^I click on New Item$/ do
pending # express the regexp above with the code you wish you had
end
When /^I fill in the item$/ do
pending # express the regexp above with the code you wish you had
end
When /^I click the button Submit$/ do
pending # express the regexp above with the code you wish you had
end
Then /^I should see the new item added to the list$/ do
pending # express the regexp above with the code you wish you had
end

Don’t forget to replace the URL in that first step with the one pointing at your index.php for your local copy of Slim. At this point we’re only implementing the first step, so that’s all we need to do for now. Once that’s done, go back to the root of the web app and run cucumber again. You should see something like this:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
TODO (Cucumber::Pending)
./features/step_definitions/todo_steps.rb:6:in `/^I click on New Item$/'
features/todo.feature:9:in `When I click on New Item'
And I fill in the item # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
1 scenario (1 pending)
5 steps (3 skipped, 1 pending, 1 passed)
0m0.036s

Our first step has passed! Now, we move onto the next step. Open features/step_definitions/todo_steps.rb again, and amend the second step definition as follows:

When /^I click on New Item$/ do
click_link ('New Item')
end

Now, hang on a minute here. This Ruby code is pretty easy to understand - it just clicks on a link with the title, ID or text ‘New Item’. But we don’t want to have to rewrite this step for every single link in the application. Wouldn’t it be great if we could have this step definition accept any text and click on the appropriate link, so we could reuse it elsewhere? Well, we can. Change the second step to look like this:

When /^I click on (.*)$/ do |link|
click_link (link)
end

What’s happening here is that we capture the text after the word ‘on’ using a regular expression and pass it through to the step definition as the variable link. Then, we have Capybara click on that link. Pretty simple, and it saves us on some work in future.

Now run cucumber again, and you should see something like this:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
no link with title, id or text 'New Item' found (Capybara::ElementNotFound)
(eval):2:in `send'
(eval):2:in `click_link'
./features/step_definitions/todo_steps.rb:6:in `/^I click on (.*)$/'
features/todo.feature:9:in `When I click on New Item'
And I fill in the item # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
Failing Scenarios:
cucumber features/todo.feature:7 # Scenario: New item
1 scenario (1 failed)
5 steps (1 failed, 3 skipped, 1 passed)
0m0.042s

We’ve got our second step in place, but it’s failing because there is no link with the text ‘New Item’. Let’s remedy that. Head back to the folder you put Slim in, and open index.php.

Here I’ve stripped out most of the default code and comments so we can see more easily what’s happening. If you haven’t used Slim before, it works by letting you define routes that are accessed via HTTP GET, POST, PUT or DELETE methods, and define what the response will be to each one. Here, we’ve defined a simple controller for GET requests to ‘/‘, and we return a template that includes a link with the text ‘New Item’.

Now, run cucumber again and you should see the following:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
Received the following error for a GET request to http://localhost/~matthewdaly/todo/newitem: '404 => Net::HTTPNotFound for http://localhost/~matthewdaly/todo/newitem -- unhandled response' (RuntimeError)
(eval):2:in `send'
(eval):2:in `click_link'
./features/step_definitions/todo_steps.rb:6:in `/^I click on (.*)$/'
features/todo.feature:9:in `When I click on New Item'
And I fill in the item # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
Failing Scenarios:
cucumber features/todo.feature:7 # Scenario: New item
1 scenario (1 failed)
5 steps (1 failed, 3 skipped, 1 passed)
0m0.153s

Our second step is still failing, but only because we haven’t yet defined a route for the destination when we click on the link, so let’s fix that. Open up index.php again and change it to look like this:

We’re just adding a new route to handle what happens when we click the link here. The new page also has a form for submitting the new item.

With that done, the second step should be in place. Run cucumber again and you should see something like this:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
And I fill in the item # features/step_definitions/todo_steps.rb:9
TODO (Cucumber::Pending)
./features/step_definitions/todo_steps.rb:10:in `/^I fill in the item$/'
features/todo.feature:10:in `And I fill in the item'
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
1 scenario (1 pending)
5 steps (2 skipped, 1 pending, 2 passed)
0m0.048s

So onto the third step. We’ve already created the input for filling in the item, so all we need to do to make this step pass is write an appropriate step definition:

When /^I fill in the item$/ do
fill_in 'item', :with => 'Feed cat'
end

With that done, run cucumber again and this step should pass:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
And I fill in the item # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
TODO (Cucumber::Pending)
./features/step_definitions/todo_steps.rb:14:in `/^I click the button Submit$/'
features/todo.feature:11:in `And I click the button Submit'
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
1 scenario (1 pending)
5 steps (1 skipped, 1 pending, 3 passed)
0m0.117s

Now we need to implement the step for clicking the Submit button. As with clicking on the New Item link, we can make this step generic to save us time later:

When /^I click the button (.*)$/ do |button|
click_button (button)
end

With that done, run cucumber again and you should see something like this:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
And I fill in the item # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Received the following error for a POST request to http://localhost/~matthewdaly/todo/index.php/index.php/submitnewitem: '404 => Net::HTTPNotFound for http://localhost/~matthewdaly/todo/index.php/index.php/submitnewitem -- unhandled response' (RuntimeError)
(eval):2:in `send'
(eval):2:in `click_button'
./features/step_definitions/todo_steps.rb:14:in `/^I click the button (.*)$/'
features/todo.feature:11:in `And I click the button Submit'
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
Failing Scenarios:
cucumber features/todo.feature:7 # Scenario: New item
1 scenario (1 failed)
5 steps (1 failed, 1 skipped, 3 passed)
0m0.210s

The step is failing here because submitting the new item generates a 404 error. We need to handle the POST. Open up index.php again and edit it to look like this:

Here we’re cheating a little bit. In a working application we’d want to store the to-do list items in a database, but to keep this tutorial simple we’ll just output the result of the POST request and leave implementing a database to store the items as an exercise for the reader.

Now, run cucumber again and you should see that this step now passes:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
And I fill in the item # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
TODO (Cucumber::Pending)
./features/step_definitions/todo_steps.rb:18:in `/^I should see the new item added to the list$/'
features/todo.feature:12:in `Then I should see the new item added to the list'
1 scenario (1 pending)
5 steps (1 pending, 4 passed)
0m0.067s

On to our final step. We want to make sure the page contains the text we submitted, which is very easy to do with Capybara. Change the final step to look like this:

Then /^I should see the new item added to the list$/ do
page.should have_content('Feed cat')
end

Now run cucumber again and you should see that the scenario has now passed:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
Scenario: New item # features/todo.feature:7
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
And I fill in the item # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Then I should see the new item added to the list # features/step_definitions/todo_steps.rb:17
1 scenario (1 passed)
5 steps (5 passed)
0m0.068s

We’re nearly done here, but first there’s a couple of other handy things you can do with Cucumber that I’d like to show you. We’ve been using the Mechanize driver for Capybara, which is very fast and efficient. However, it’s effectively a text-mode browser like Lynx, so it can’t be used to test any functionality that relies on JavaScript. However, Mechanize isn’t the only driver available for Capybara, and you can switch to the JavaScript driver when necessary so you can test. The default JavaScript driver is Selenium, which will launch an instance of Firefox and use that for the test.

It’s easy to switch to the JavaScript driver when you need it. Just tag the scenario with @javascript, as in this example:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
@javascript
Scenario: New item
Given I am on the home page
When I click on New Item
And I fill in the item
And I click the button Submit
Then I should see the new item added to the list

Now run cucumber again and this time it will fire up an instance of Firefox and use that to run the tests. This can also be handy for debugging purposes since, unlike with Mechanize, you can see the pages.

Finally, what about if you want to test the same functionality multiple times with different input? You don’t want to have to write out multiple scenarios that are virtually identical, even if you have refactored them to make them more useful. What you need is a way to repeat the same test, only with different input each time.

Handily, Cucumber can do this too. First, let’s refactor the code for our step definitions so the final step can handle any text:

Given /^I am on the home page$/ do
visit "http://localhost/~matthewdaly/todo/index.php"
end
When /^I click on (.*)$/ do |link|
click_link (link)
end
When /^I fill in the item with (.*)$/ do |item|
fill_in 'item', :with => item
end
When /^I click the button (.*)$/ do |button|
click_button (button)
end
Then /^I should see the text (.*)$/ do |text|
page.should have_content(text)
end

Here we’ve changed the third and fifth items so we can pass any value we want through to them. As I mentioned earlier, this is good practice since it means we don’t have to write more code for our tests than we need to.

With that done, open up the feature file and amend it to look like this:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
@javascript
Scenario Outline: New item
Given I am on the home page
When I click on New Item
And I fill in the item with <item>
And I click the button Submit
Then I should see the text <item>
Examples:
| item |
| Feed cat |
| Stop milk |
| Take over world |

If you then run cucumber again, the scenario should run three times, each time entering different text:

Feature: Todo
In order to use the site
As a user
I want to be able to submit, view and delete to-do list items
@javascript
Scenario Outline: New item # features/todo.feature:8
Given I am on the home page # features/step_definitions/todo_steps.rb:1
When I click on New Item # features/step_definitions/todo_steps.rb:5
And I fill in the item with <item> # features/step_definitions/todo_steps.rb:9
And I click the button Submit # features/step_definitions/todo_steps.rb:13
Then I should see the text <item> # features/step_definitions/todo_steps.rb:17
Examples:
| item |
| Feed cat |
| Stop milk |
| Take over world |
3 scenarios (3 passed)
15 steps (15 passed)
0m25.936s

With only a few changes, we’re now running the same scenario over and over again with different input, and testing the output is correct for each one. This makes it very easy to test repetitive content. For instance, if you had an e-commerce site with lots of products and you wanted to test the pages for some of the products, you could put them in a table like this. You can have more than one column if necessary, so you could write a scenario like this:

Scenario Outline: Test products
Given I am on the home page
When I search for <product>
And I click on the first result
Then I should not see any errors
And I should see the text <productname>
Examples:
| product | productname |
| supersprocket | Super Sprocket 3000 |

As you can see, Cucumber is a really simple way to start testing your web apps, and can really improve the quality of your code. Even if you’ve never used Ruby before, Capybara’s API is very simple and intuitive, and should adequately cover most of what you need to do when testing a web app.

As I mentioned, the PHP community in general has been a bit slack in terms of getting proper automated tests working. But Cucumber makes it so simple, and offers so many other benefits, such as human-readable tests and getting stakeholders more involved in the development process, that there’s really no excuse not to use it. Hope you’ve enjoyed this tutorial, and that it’s encouraged you to start using Cucumber to test your own web apps.

]]>https://matthewdaly.co.uk/blog/2012/04/23/yet-another-tutorial-for-building-a-blog-using-python-and-django-part-5/
https://matthewdaly.co.uk/blog/2012/04/23/yet-another-tutorial-for-building-a-blog-using-python-and-django-part-5/Mon, 23 Apr 2012 20:55:40 GMTIn this instalment I’ll be showing you how we can make our blogging engine a little nicer to look at by adding some CSS and images, as well as expanding on Django’s templating system.

First of all, let’s add some CSS to our blog. When developing a web app with Django, you should place static files such as stylesheets and images in a folder inside your app (not project) folder called static. My project is called DjangoBlog, and my app is called blogengine, so all my static content should go in DjangoBlog/blogengine/static/. Here’s the stylesheet, which I’ve saved as style.css:

In the same folder, I have a PNG icon for an RSS feed, and if you had some JavaScript files you wanted to use (such as a copy of jQuery), you would put them here too. Note that there’s nothing to stop you creating subfolders within /static, and in fact I would recommend you do so for any future project so you can separate out images, CSS and JavaScript easily.

With that done, we now need to change our templates to make use of this CSS. Here’s what header.html should look like:

Here, we first of all load the flat pages. Then we retrieve them, and loop through each of them. For each page, we create a new list item containing a link to the flat page, with the text being the flat page’s title. Note that we’re just referring to each flatpage object’s attributes here. Then we end the for loop.

The only problem with this is that all of the pages except the flat pages are handled by the blogengine application, not the flatpages one, so we can’t get the values for the flat pages, so we need to amend blogengine/views.py. Open it and add the following line near the top:

from django.contrib.flatpages.models import FlatPage

Now, nowhere else in the view is the FlatPage application needed, but it’s required in the template, so by importing it here we make it available in the template.

With that done, our Django-powered blog is beginning to look a bit more presentable, so I’ll leave it to you to style it however you wish, using this as a starting point. The blog is now pretty much feature-complete, however there’s one more thing I’d like to demonstrate before we finish up, namely generic views.

As you may have gathered by now, Django uses slightly different terminology to many other web development frameworks. Although it can be considered an MVC (Model-View-Controller) framework like many others, it’s generally referred to as an MTV (Model-Template-View) framework, with views containing the logic needed to present the data. While Django ships with a number of built-in applications to do certain repetitive tasks easily, not every task lends itself well to being handled by one generic application. However, these tasks may still require something similar be implemented over and over again, and that’s what generic views are for.

We don’t yet have a list of all of the available categories, so let’s use a generic view to do that. In urls.py, add the following lines at the top:

Then, add the following lines at the top of the section for categories:

url(r'^categories/?$', ListView.as_view(
model=Category,
)),

Then, go into your templates folder and create a new folder in there called blogengine (or whatever you’re calling your blog application). In there, create a new file called category_list.html and enter the following code in it:

Now, you didn’t write a view for this at all. Instead, this is handled by a generic view. In urls.py, we imported the ListView generic view, which is nothing more than a list of objects. We then import the Category model. Then, we define a URLconf that maps the categories/ url to ListView, which displays a list of all the Category objects. The template used is determined automatically, and we create that template as normal. Note that in the template we refer to object_list - this demonstrates that we’re referring to the objects passed through generically, and in theory this same template could display any objects with attributes called title and description.

Now, it probably won’t have escaped your notice that a blog is effectively a list of posts, so can’t we use a generic view to display them? Well, yes we can! So why don’t we cut down on the amount of code we need to maintain and use a generic view, rather than writing our own view?

Go into blogengine/views.py and delete the getPosts function in its entirety. Next, go into urls.py and delete the part that deals with showing the posts (the two lines just under the Home page comment), and replace them with this:

Note here that we specify how many items we paginate by. The ListView generic view supports pagination, making it ideally suited for any list of objects that may be spread across multiple pages - you just import the model you want and pass it through in the model parameter.

We also need to import the Post object in urls.py. Amend the line where you imported the Category model as follows:

from blogengine.models import Category, Post

Then move posts.html into your templates/blogengine folder and rename it post_list.html, then amend it to look like the following:

The changes here are minimal, just adjusting the names of objects to what the generic view uses. Now, if you refresh the browser, you should be able to see your blog posts, only now they’re being handled by Django’s ListView generic view. But they’re in the wrong order, so go into blogengine/models.py and add this code to the Post model:

class Meta:
ordering = ["-pub_date"]

This defines the order the Post objects should be in the model, rather than the view. If you now refresh the browser, they should be in the right order.

A ListView is only one of the generic views available in Django. There are others that are useful under other circumstances, but they’re beyond the scope of this tutorial, so I suggest that if you’re interested, you take the time to learn more about them on your own. They can save you a lot of time and effort if used well.

Sadly, that brings this series of tutorials to an end. I hope you’ve enjoyed learning about Django, and I hope you’ll be inspired to build something cool with it! As always, the code is available on GitHub, so feel free to download it, use it as the basis for your own projects, or whatever else you’d like to do with it.

Categories are somewhat tougher to implement than most of what we’ve done beforehand. One category can be assigned to many blog posts, and many categories can be assigned to one blog post, so this relationship is described as a “many to many relationship” when drawing up the database structure. What it means is that you can’t directly map categories onto posts and vice versa - you have to create an intermediate database table for the relationship between posts and categories.

We’re adding quite a bit of new code here. First of all we’re defining a new model called Category. Each category has a title, a description, and a slug (so we can have a dedicated page for each category). As usual, we define methods for unicode and get_absolute_url, but also note the class Meta. Here we’re defining some metadata for the class (ie, data about the data). The only thing we do here is essentially telling the admin interface that the plural of Category is not “Categorys” but “Categories”.

Then, in Post we add an additional field called Category, which we define as a ManyToManyField. Note the parameters passed through - we’re saying here that a post need not be assigned a category, and that CategoryToPost should be used as an intermediate table to link posts to categories.

Finally, we define the aforementioned CategoryToPost model, which has two fields, post and category. Both of these are foreign keys, mapping to a blog post and a category respectively. By creating entries in this table, a link can be created between a post and a category.

Here we define a new class called CategoryAdmin, which details how we’re changing the admin interface for Category from the defaults generated from the fields provided. The only change we make here is that we prepopulate the slug field from the title, much like we did with blog posts.

Next, we define an inline for the relationships between categories and post, called CategoryToPostInline. This is a new concept - essentially it means that the category to post relationships can be defined in another model’s admin interface. We define the model this applies to, and that by default we will only add one additional field for adding categories when writing or editing a post (though users can add as many as they wish, or none). Note that the model this is based on is admin.TabularInline - this represents a tabular layout. If you prefer, you can use an alternative layout by using StackedInline instead.

Then, in PostAdmin we add our newly declared CategoryToPostInline to the PostAdmin class as an inline. Finally, at the bottom we register Category with the admin interface, so we can create and manage categories easily.

Here we import the Category model as well as the Post model. Then, the only additional change we need to make is to add a brand new getCategory view function. Note that this is quite similar to the getPosts function - we set up pagination in the same way, and rather than get all the posts, we get just those in the specified category. Also note that we’re using the template category.html rather than posts.html here, and we pass through category as well as posts and page when we return the render_to_response.

The next change we need to make is adding category.html. Go into your template directory and save the code below as category.html:

Comments can be attached to any type of content, but we only want to attach them to blog posts, and they should only be visible in the single post template. But first of all, let’s add a comment count to posts in posts.html and category.html. Replace posts.html with this:

The only significant changes here are that at the top we load comments, and underneath the post text we get the comment count for each post as the variable comment_count, then we display it underneath.

Now, we want to go further with our single post template. As well as a comment count, we want to add the actual comments themselves. Finally, we need a form for adding comments - in theory you can use the admin interface for doing this, but it’s very unlikely you’d want to do so. Open up single.html and edit it to look like this:

This includes the same changes as the other two templates, so we load comments and display the comment count. Afterwards, we get the comment list for this post as comments, and then loop through the comments, showing them in an ordered list. Afterwards, we then use render_comment_form to show the default comment form for this post. If you’d prefer to create your own comment form, you can use get_comment_form instead to get a form object you can use in the template.

You’ll also need to make some minor changes to the view to get the form working. Save single.html and open blogengine/views.py and add the following line of code to your import statements:

The reason this needs to be changed is that the comment form includes the {% csrf_token %} tag, which requires information from the request object, and in order to do so rather than the default context, you need to pass through a RequestContext object instead, but don’t worry too much about the details.

If you now ensure the development server is running and visit a blog post, you should now see that you can post comments. If you want to enhance this very basic comment form, take a look at the excellent documentation on the Django website. Alternatively, there are a number of third-party comment services, such as Disqus and IntenseDebate that can handle comments for you and just require you to paste a snippet of code into whatever template you want to enable comments on, and these may be more convenient.

Finally for this lesson, as promised, we’ll implement our RSS feed. Again, there’s an application bundled with Django that will do this - the syndication framework. Open settings.py and paste the following line in at the bottom of your INSTALLED_APPS:

'django.contrib.syndication',

Save the file and run python manage.py syncdb to add the appropriate tables to your database. Then, we need to add a URLconf for the RSS feed. We’ll allow a consistent naming scheme for RSS feeds, so this will be /feeds/posts, and if you wanted to you could add /feeds/comments, for instance. Add this to you urls.py, before the url for flat pages:

# RSS feeds
url(r'^feeds/posts/$', PostsFeed()),

We’ll also need to tell urls.py where to find PostsFeed(). In this case, we’re going to put it in the view, so add this import line near the top:

from blogengine.views import PostsFeed

Now open blogengine/views.py and add the following line to the import statements at the top:

This is pretty simple. We import the Feed class from thew views provided by the syndication framework, then we base PostsFeed on Feed. We set the title, the link for the feed, and a description for the feed. Then we get the last 5 Post objects in reverse chronological order, and we define each item’s title as the post title. and each item’s description as the text of the post. From here’ it’s pretty easy to see how you could create feeds based on comments, or pretty much any other object that might exist in the database.

And with that done, our blogging engine is pretty-much feature-complete. We have blog posts with comments, categories, an RSS feed, and flat pages, but the look and feel of the site definitely needs some attention. Next time, we’ll make our blogging engine look a little nicer. Once again, the code is available on GitHub in case you find that more convenient.

]]>https://matthewdaly.co.uk/blog/2012/03/24/yet-another-tutorial-for-building-a-blog-using-python-and-django-part-3/
https://matthewdaly.co.uk/blog/2012/03/24/yet-another-tutorial-for-building-a-blog-using-python-and-django-part-3/Sat, 24 Mar 2012 18:23:25 GMTWelcome back! In this installment, we’ll make some changes to our URL structure for blog posts, we’ll add support for multiple authors and static pages, and we’ll add some more templates.

First of all, our URL structure. The existing structure works fine, but it would be better if we included a representation of the date of publication. If you’re familiar with WordPress, you’ll know it offers several different URL forms, one of which is the post name alone as we’re using here, and another of which is the year, month and name. We’ll use the latter of these URL schemes with our blogging engine.

This seems like a good opportunity to introduce the interactive Python shell that comes with Django. Make sure you have a few dummy posts set up, then in the project directory (DjangoBlog/, not the top-level one but the one inside that), enter the following command:

python manage.py shell

This will start up an interactive Python shell which you can use to interact with your Post objects. Now, the first step is to import your Post model:

You may have completely different post objects, or a different number of them, but that’s fine. Remember we set __unicode__(self) to return self.title? Here we see that each blog post is represented by its title. Now let’s get one of our Post objects:

>>> p = Post.objects.get(pk=1)
>>> p
<Post: My first blog post>

In the first line above, we get the Post object with the primary key of 1, and store a reference to it as p. We then demonstrate that it is, indeed, one of our blog posts by outputting its title.

If you’re not familiar with relational database theory, a primary key is a value in a database table that refers uniquely to one entry in the table, so that if you refer to an entry by its primary key, you can be sure you’re getting the correct value. By default, Django models generate a field called id in addition to the ones you define, which is set as the primary key, and this is set to auto-increment, so for instance, every time you add an additional blog post, it gets the next number as its id. Here, we just want to get access to a single blog post object, so we just enter 1 as the primary key in order to get the earliest blog post.

Next, we get the publication date:

>>> p.pub_date
datetime.datetime(2012, 3, 19, 12, 11, 10)

This returns a datetime.datetime object. If you look at the documentation for Python’s datetime module, you’ll notice that it has attributes called day, month and year. Here’s how we can use these to get the information we want:

Now, you haven’t seen get_absolute_url before. Every time you create a model in Django, you should really create a get_absolute_url method for it. In essence, it defines a single, canonical URL for that object, whether it’s a blog post, a user, or what have you. By creating one method that defines the structure for the URL for this type of object and referring to it elsewhere, we only need to change it in one place if we want to make any changes to how we determine the URL for that type of object.

What we do here is we define the URL as being /year/month/slug/. If you want, you can quite easily make it include the day as well like this:

What we’ve changed here is that we’ve told urls.py to expect blog posts that look like 4 digits, then a forward slash, then one or two digits, then another forward slash, then a slug that can include hyphens, upper or lower case letters, and numbers.

With that done, we just need to update our template. Edit templates/posts.html to look like this:

Literally all we do is replace post.slug with post.get_absolute_url and remove the leading forward slash. If you then run python manage.py syncdb, restart the development server and go clicking around your posts, you should be able to see that our new URL system is now up and running.

With that done, the next step is to add support for multiple authors. Now, you might think that we’re going to have to create a new model for users, but that’s not so – Django ships with a number of useful models already, and we’re going to use one of them here.

Now, first of all, we need to amend our Post model to include the author’s details. Edit your blogengine/models.py to look like this:

There are two significant changes here. First, we import User from django.contrib.auth.models. User is a model provided by the auth model, and we’re going to use it here to represent the author of a given post. Then in the class definition of Post, we add a new field called author.

Note here that author is a foreign key field, and is passed a User object. Again for those unfamiliar with relational databases, a foreign key is a field in a database table that is also a primary key in another database table. Here we’re declaring that the author is one of the entries in the User table.

As well as this, we need to make some changes to the admin interface. By default, when we make a field in a model a foreign key, the admin interface will show a dropdown list of all of the instances of that object (so here, it would be a list of all the users on the system). But we don’t want that. We want the author to automatically be set as the current user, and for there to be no way to override this.

However, the new object won’t actually be stored in the database properly until you call the save() method. Here, you would need to enter p.save() (Note this won’t actually work unless you enter all the fields manually). What we’re doing in admin.py is overriding the default save() method to set the author to the name of the user who wrote the post.

Now run python manage.py syncdb again. Note that as you’ve changed the Post model, your existing posts will be lacking the required author field, and so you may need to add these again manually – this will be a numeric ID mapping to a user id. If you only have one user set up, you should just be able to set this to 1 by using an UPDATE SQL query.

If you now make sure the development server is running and log into the administrative interface, the first page you see should have a section marked “Auth”, with two items underneath named Groups and Users.

Now, cast your mind back to when you activated the admin interface and synced the database. If you recall, at this time you were asked to create a superuser account in order to log into the admin interface. This was actually provided by the django.contrib.auth application, one of the applications that are shipped with Django and are active by default. This contains the User and Group models.

If you’re familiar with Linux or Unix, the Auth application will feel very familiar. The account you created at the start was a superuser account, much like the root account on a Unix system, with unlimited privileges. Other users can be created, and given permissions on an individual basis. You can also create groups and add users to those groups, and then set the privileges for those groups en masse. For instance, in a large collaborative blog with many authors, you may have one group for people who contribute articles who can create new posts, editors who can edit existing posts and so on. Similarly, if you had a working comments system, you could easily set up a moderators group who can delete comments, and add people to that group.

Let’s create another user account so we have more than one. From the main admin page, click on the link for Add next to Users. You’ll be taken to a screen that prompts you for a username and password for the new user. Fill these in (there are two password fields for confirmation purposes) as you wish – here I’m setting the new user as bob. On the next screen you can add some additional details for the new user account, such as first name, last name and email address – do this so you have some information to work with.

Lower down you’ll see a dialogue for entering the permissions. You can make the new user a superuser so that they have permission to do anything, you can say whether or not they are staff (they need to be staff to use the admin interface, so check that), and whether they are active (making it easy to deactivate a user account without the need to delete it). Below you’ll see another dialogue showing the available permissions and allowing you to allocate them to that user. Further down, you’ll see a dialogue for changing the start date and last login date for the user, and finally a dialogue for adding new groups and adding the user to existing groups.

Save the user details once you’re done, then go into your superuser account and add a first and last name so we have some data to work with for that as well. Note that just as with a root account on a Unix box, it’s not a great idea to use a superuser account for everyday work (you should create an account that has the minimum privileges you need and use that), but we’ll stick with it for now just for learning purposes – don’t forget if you should roll out a public facing Django-powered site in future, though!

With that done, we now have some data to work with to identify the author of a given post. Let’s fire up the interactive shell again with python manage.py shell:

Here, we can see that it’s easy to get the author’s details from the post. We define p as a reference to the single Post object,then we get the author, which in this case is called root. As I’ve defined a first and last name, we can get those too with p.author.first_name and p.author.last_name, which are strings containing the first and last name respectively. Note the ‘u’ before the string – this just indicates that the string is Unicode.

So from here, it’s pretty easy to display the author’s name in each post. Go into templates/posts.html and add the following line where you want your author details to appear:

<h3>By {{ post.author.first_name }} {{ post.author.last_name }}</h3>

Now, as long as you’ve added a first name and last name to that author’s details, if you visit http://127.0.0.1:8000, you should see the appropriate details.

Our next step is to add the facility to create flat pages, somewhat like the Pages functionality in WordPress. Again, Django comes with an application that will handle this, called flatpages, but it’s not enabled by default. Go into DjangoBlog/settings.py and at the bottom of INSTALLED_APPS, add the following:

'django.contrib.flatpages',

Then run python manage.py syncdb again to add the appropriate tables to your database. Now, we need to add a flat page. Go back to the main page of the admin interface, and you should see that you now have the facility to add flat pages. Click on the Add link for flat pages, and give your page a URL, a title, and some text (here I’m giving it a URL of /about/ and a title of About), add it to a site at the bottom (this will say example.com, but don’t worry about that, it’s to do with the Sites application, which we’re not looking at right now) then save it. You should now have a FlatPage object available.

Let’s take a look at the tables created for flatpages using the sqlall command:

So we can see that django_flatpage, which contains the details about the actual flat pages, has the fields id, url, title, content, enable_comments, template_name, and registration_required. Some of these options are under the advanced options in the flat page interface, so you may have missed them.
Now fire up python manage.py shell again:

Here we have one FlatPage object only (note that get() should only be used if you will only get one result back), which is represented by a string that includes the URL and title.

>>> f.content
u'This is my about page.'

We can easily access any of the fields in the flat page. Now, we need to define some URLs for our flat pages. Exit the Python shell and open urls.py, then insert the following rule underneath the one for blog posts:

# Flat pages
url(r'', include('django.contrib.flatpages.urls')),

Note that this must be the last rule in your urls.py, because it will match anything. Now, you can try and load /about/, or whatever page you’ve created, but you’ll get an error stating that the template does not exist, so we need to create that. Go into your template directory, and create a directory inside that called flatpages. Then create a new file in there called default.html, and add the following code to it:

Now, make sure you have the development server running and try to load http://127.0.0.1:8000/about/, or whatever your flat page URL is, and you should see your flat page’s title and content.

One final task for this lesson – we’re going to refactor our templates a little so that as little code as possible is duplicated and if we want to change anything we need to only do so in one place. Go to your template directory and edit posts.html to look like this:

Here we’re taking the header and footer of the page out and replacing them with code that includes another file there instead. Next, we need to create those files in the same directory. Here’s header.html:

<html>
<head>
<title>My Django Blog</title>
</head>
<body>

And here’s footer.html:

</body>
</html>

None of this is terribly complex – we’re just moving the code into another file so that other templates can use the same files. Now save a copy of posts.html as single.html – we’re going to create a template for a single blog post. Edit the original posts.html to look like this:

We’re just removing the date and author details from the template that shows multiple posts. Our existing single.html file can remain as it is for now, since that still has all the additional information we want to include in an individual post.

While we’re here, let’s update our flat pages to use the same header and footer. Go into the flatpages directory and change default.html to look like this:

Note that the path to the template files is not relative to flatpages/default.html, but relative to the root of the template directory.

The last thing to do is to amend the view for our blog to use the correct templates. Go into blogengine/views.py and change the getPost (NOT getPosts) function to pass the single.html template to render_to_response, instead of the posts.html template:

You should now notice that the single posts and multiple posts are using different templates.

Hope you’ve enjoyed this lesson, and I’ll do another one as soon as I can. The code is available on GitHub if you prefer to get it that way.

]]>https://matthewdaly.co.uk/blog/2012/03/19/yet-another-tutorial-for-building-a-blog-using-python-and-django-part-2/
https://matthewdaly.co.uk/blog/2012/03/19/yet-another-tutorial-for-building-a-blog-using-python-and-django-part-2/Mon, 19 Mar 2012 15:18:57 GMTIn the first part of this tutorial, we got the core elements of our blogging application working - we set up our model for posts, and a view, template and URL configuration to view the index. Next we’ll start extending this very basic functionality - we’ll add a view for individual posts as well, and we’ll allow for each post to have a separate URL.

First, we need to set up some pagination for the home page. At this point, it’s worth taking the time to look at how we want our URL to look. Here, we’ll work on the basis that by default, the home page will show the first five blog posts, and if someone wants to see later posts, they need to append a number to the end. Here’s the URL for the second page assuming it’s at example.com:

http://www.example.com/2/

So, we need two separate rules for the URLs. We need one for a URL with no number at the end, and one for a URL with a number at the end, and an optional forward slash. Open up urls.py and edit it so the Home page section looks like this:

Note that I’ve edited the first rule to include ^$ as the regular expression. ^ denotes the start of a regex, and $ denotes the end, so this represents a URL with nothing added after the domain name, such as http://www.example.com. We’ve also changed getRecentPosts to getPosts, as that’s now a more descriptive name.

The second line will match if there is a digit (denoted by the \d+ section) and will pass that digit through to the getPosts function as selected_page. With that done, we now need to make the necessary changes in the view, so move into the blogengine directory and amend views.py to look like this:

Again, note the change in function name from getRecentPosts to getPosts. Now, let’s work through the rest of the code. You’ll notice the following line near the top:

from django.core.paginator import Paginator

This imports the Paginator class, which is very useful for creating pagination. Then, you’ll notice the following line:

def getPosts(request, selected_page=1):

If you know much about Python, you’ll know that you can specify a default value for a parameter passed to a function or method. Here, what we’re doing is setting the default value of selected_page to 1, so if someone visits http://www.example.com, for which the URLconf doesn’t specify a number, this defaults to 1. If they visit http://www.example.com/2 instead, the default value for selected_page will be overriden to 2.

Then you’ll note that we’ve refactored the lines that fetched the posts and sorted them into one line, and called that posts. After that we define pages as a Paginator object, and passed it the values of posts and 5. The first parameter is what we want to divide between pages, and the second is how many instances of this we should allow on an individual page. Here we’re passing through all of the posts, and allowing 5 posts per page. We then define returned_page as the page from pages that matches the number submitted in the selected_page variable. Finally we pass a list of all the objects that make up returned_page through to the template as posts.

So, we now have basic pagination in place. Next, we’ll add the capability to display individual posts.

Now, we could just be lazy and have each post referred to by the numerical ID that’s automatically added by Django to the database, but why would we want to do that? We want a nice, human and search engine friendly URL that gives some idea what the blog post is about. Django is structured in such a way that nice, friendly URLs without cruft are very easy to create, and it actually has a special type of field in the models called a slug field that’s ideal for creating URLs.

So first of all, go into blogengine/models.py and edit it to look like this:

The only change is the addition of the slug field. Like any other field, you’ll be able to edit the slug field using the admin interface. But, why should you have to? Existing blogging solutions like WordPress will suggest a URL for a blog post, so that’s what we want to do as well. Open blogengine/admin.py and edit it to look like this:

If you know a little about object-oriented programming in Python, you should be able to grasp what’s going on here. We’re creating PostAdmin, which inherits from ModelAdmin, and using the title to prepopulate the slug field. We then register this as before, but using PostAdmin rather than the default ModelAdmin.

A fairly typical slug will be based on your title, but will strip out whitespace and other characters between the words and replace them with hyphens, and convert the result to lowercase, so a title like “My new bike” will become my-new-bike.

Also, note that in models.py, we pass the parameter unique=True for the slug. This indicates that the slug must be unique, so we can’t have the same URL applied to two different posts.

With our model and admin amended, it’s now time to create a view to deal with displaying an individual post. Add the following function to blogengine/views.py:

This function receives the request object and a slug for the post. It then gets the specific post with that slug, and returns it. For now we’ll just use the existing posts.html template, but we’ll want to add a new template for single posts at some point.

With that done, the next step is to add a URLconf to handle blog posts. Open urls.py and add the following code after the lines for the home page:

So, now we have a dedicated URL for each post. But how do we get there? We need to create a link from the home page to each individual blog post. Open up your posts.html template and edit it to look like this:

Now, if you run python manage.py syncdb, the changes to your database schema will be made automatically. However, if you already have some test posts in the database, these won’t have a slug and that could cause problems. So you can either add slugs to the existing posts manually using an UPDATE SQL command, or if you’re using something like PHPMyAdmin you can use that to add slugs for these posts. Or if they’re just test posts and you don’t care about them in the slightest, just delete your database and start again from scratch.

With that done, if you then run python manage.py runserver, and then visit http://127.0.0.1:8000, you should see your home page. If you have at least one blog post set up, you should see those posts on the home page, and the title should be a hyperlink to that post. If you have more than 5 posts, you should be able to go to http://127.0.0.1:8000/2 and see the next 5 posts.

But wait! What if you don’t have more posts? You want some code in place to handle what happens if you try to go to http://127.0.0.1:8000/2 and it isn’t there. You also want to dynamically generate links for older and newer posts so that users can click back as far as they need to.

First of all, let’s put something in place to catch nonexistent pages. Open blogengine/views.py and edit the getPosts function to look like this:

The only differences here are that EmptyPage is imported, and we add error checking to returned_page so that if it throws an EmptyPage exception (meaning that the given page doesn’t exist), then it defaults to returning the highest numbered page. The value of pages.num_pages is the number of pages in total, so you use this to get the last numbered page. If you prefer, you can change it to default to the first page by replacing pages.num_pages with 1.

With this done, the next step is to create links for the next and previous pages. Fortunately Django makes this really easy. First, you have to pass through the returned_page object in views.py, like this:

Here, if the given page has a previous page, we display a link to it, and if it has a next page, we display a link to that too. page.has_previous and page.has_next return True or False, and page.previous_page_number and page.next_page_number display a number for the appropriate page, so it’s easy to use them to link to the appropriate page.

And that will do for now! We’ve gotten quite a lot done this time, and we actually have something that, although it’s still missing many of the more sophisticated features of blogging platforms such as WordPress, is fundamentally usable as a blog as long as you either don’t want comment functionality or are prepared to use a third-party system such as Disqus. Feel free to congratulate yourself with a beverage of your choice, and we’ll carry on later.

]]>https://matthewdaly.co.uk/blog/2012/02/28/new-theme/
https://matthewdaly.co.uk/blog/2012/02/28/new-theme/Tue, 28 Feb 2012 18:25:30 GMTFor a long time now, I’ve kept meaning to write my own WordPress theme from scratch for this site, but just haven’t been able to find the time to do so. Now, I’ve finally found the time to do so, and here it is!

Please let me know what you think, but be gentle (this is my first solo WordPress theme, and also the only one I’ve built completely from scratch), and if you find any issues with it please let me know. Don’t expect it to look great in IE6 or IE7 however - I’ve given it a very cursory review in those browsers, and that’s all. It’s still perfectly readable, but it uses a fair amount of CSS3 so it’s inevitably not going to look as pretty in those browsers.

]]>https://matthewdaly.co.uk/blog/2012/02/24/yet-another-tutorial-for-building-a-blog-using-python-and-django-part-1/
https://matthewdaly.co.uk/blog/2012/02/24/yet-another-tutorial-for-building-a-blog-using-python-and-django-part-1/Fri, 24 Feb 2012 16:17:10 GMTWhile I’m extremely fond of Perl for quick hacks and scripts, and have used PHP a fair amount for web development purposes (both on its own and with the CodeIgniter framework), there is one language I love above all others, and that’s Python. I’ve found that, when compared to PHP or Perl, at least for me, it’s a lot easier to “get into the zone” when programming in Python, the code I produce tends to be a lot more readable and easier to follow, and the interactive interpreter makes it really easy to figure out what’s going on in a way that just isn’t possible with PHP or Perl. Also, Python was always designed to be an object-oriented language, and IMHO has a better object model than either Perl or PHP.

While it would be fair to say that Python doesn’t have a single web development framework that monopolises developer’s attention the way Rails does for Ruby programmers, Django is undoubtedly the best-known Python framework. It’s solid, easy to use, and has the best documentation of any web development framework I’ve ever seen (don’t get me wrong, CodeIgniter in particular has very good documentation, but Django’s is exceptional).

In this tutorial, we’re going to build a very simple blogging engine using Django. In its initial stages, it will be an extremely simple web app - we won’t bother with comments, tags, categories or multiple users , or any of the other niceties of a fully-fledged blogging engine. Instead, we will build a very basic Tumblr-style blogging engine, capable of publishing blog posts and very little else. As time goes by, we can add further functionality to this and build it up into a more capable blogging solution.

So, let’s get started. Go to the Django project website and download the latest release (NOTE: as at time of writing this was 1.3.1, but we’re now up to 1.4.3 as at 14 January 2013, and some changes have been made to Django’s structure). Follow the installation instructions given there, and you should be ready to go. Note that from here on, I’m assuming you’re using a Unix-like operating system such as a Linux distro or Mac OS X - if you’re using Windows, there’s a few extra steps you’ll have to take, such as installing Python, and some of the commands you use may be different.

Once Django is installed, find a suitable folder in which to store your new Django project (perhaps a Projects folder in your home directory might be a good place). Note that Django includes its own development server, so you don’t need to install a full LAMP stack like you would if you were developing in PHP. Then, from the folder you want to store your project in, run the following command:

django-admin.py startproject DjangoBlog

This will create a brand-new directory containing all the files you need for your new Django project. If you now cd into this directory, you should see manage.py, as well as a folder called DjangoBlog containing the files __init__.py, settings.py and urls.py.

Let’s go through what these files do. First of all, there’s __init__.py - don’t worry about this, it’s a blank file and you don’t need to touch it.

Next, manage.py contains a number of extremely useful commands that you will find handy when using Django. You’re unlikely to need to edit it, but you’ll use it a lot.

Next, settings.py is the settings for the web app you’re building. It will specify details like what Django applications you’re using, what timezone you’re in, your database connection details and so on. You’ll need to edit this, so open it up in your favourite text editor.

Look for a line that reads “DATABASES”. Under here you’ll notice the following line:

You can use pretty much any relational database you like with Django, and because it uses its own Object-Relational Mapping (ORM), it generates the SQL needed for you, taking into account any quirks in that particular database engine. It therefore doesn’t really matter what database you use, and it’s easy to swap them out. For development purposes, we’ll use SQLite as it ships with Python and requires less configuration, so change this line to read as follows:

It really doesn’t matter what you call the file. I tend to call mine backend.db, as follows:

'NAME': 'backend.db', # Or path to database file if using sqlite3.

If you keep going down, you’ll notice TIME_ZONE and LANGUAGE_CODE. You may wish to change these from their default settings (I change mine to Europe/London for TIME_ZONE and en-gb for LANGUAGE_CODE).

Even further down, you’ll notice the INSTALLED_APPS section. Django distinguishes between a project and an application - while a project will normally be a single website, an application will be a set of functionality within that website. For instance, our blog will be a single application, but we could reuse that application on multiple projects. Django also includes a number of applications out of the box - for instance, the flatpages and admin applications can be used together if you wanted to use Django to build a simple CMS, without having to build a new application at all.

For now, we don’t need to add any new applications, so let’s save the changes we’ve made to settings.py and move on to urls.py. This handles directing any incoming HTTP requests to the appropriate place to deal with them. It uses simple regular expressions to evaluate the incoming requests, and maps them to specific view functions. Note that it already includes URLs for the admin functionality, but these are commented out by default.

Exit urls.py and head back to the main directory for your project. Now, we need to test that everything works OK. Run the following command:

python manage.py runserver

Remember I said that the manage.py script had a lot of useful functions? This is one of them. Django has its own simple web server so you don’t have to faff around setting up Apache just for development purposes, and this launches it. If you go to http://127.0.0.1:8000, you should see a screen telling you that Django is running.

Now, you can stop the server for now using Ctrl-C, and we’ll start work on your new app. Run the following command to create your new app:

python manage.py startapp blogengine

Again, note that you used manage.py to do this. There should now be a directory called blogengine in your project. Move into it, and you should find that it contains four files - __init__.py, models.py, tests.py and views.py. Again, __init__.py can be safely ignored, and tests.py can also be left alone, but models.py and views.py deserve closer examination.

If you haven’t used an MVC framework before, then you’ll need this explaining. MVC stands for Model-View-Controller, and it describes a method of logically separating out code for a web application to make it easier to work with. Models represent the data held by the application, views represent what end-users see of the application, and controllers represent the logic that ties the two together.

Django uses a slightly unusual interpretation of MVC. The models work exactly the same as they do in other frameworks, but the logic is handled by the view, and the presentation is handled by templates. Compared to more conventional MVC frameworks such as CodeIgniter, Django’s views are more like controllers, and its templates are more like views. Django is therefore often described as an MTV framework (Model-Template-View), instead of an MVC one.

So, to create our blog, we first need to create a model to describe the data. Edit models.py so it looks like the following:

To activate our new app, we also need to include it under INSTALLED_APPS in settings.py:

'blogengine',

In Django, you create your models as Python classes, which makes it very easy to grasp. Here, a blog post is an object, and it has a title, a publication date, and some text. Note that Post here inherits from models.Model, and has specific types of field that map to field types in the database table. For instance, models.CharField obviously maps to a VARCHAR field in the database, and TextField maps to a TEXT field. You can actually see the SQL that will generate the database table for this model by returning to the project’s main directory and running python manage.py sqlall blogengine:

Note the “id” field. You didn’t add this - by default, Django will create an id field in any new table, and will make this the primary key in that database table. You can, however, override this behaviour if you wish. Here it’s exactly what we want so we’ll stick with it for now.

Also note the unicode method. This represents a string that describes that object. Here the title of a blog post seems the most logical way of describing it, so we return the object’s title.

Now that we’ve got our model set up, how do we get the information into it? For a blog post, all of the information will be submitted by the user, so we need to set up some kind of administrative interface. Fortunately, one of Django’s killer features is the admin interface that ships with it. This makes it really quick and easy to get certain kinds of sites up and running.

First of all, we need to activate the admin application. Head up to settings.py and uncomment the line that reads:

'django.contrib.admin',

Save it, then head for urls.py and uncomment the following lines:

# from django.contrib import admin
# admin.autodiscover()

And:

# url(r'^admin/', include(admin.site.urls)),

Now, in order for the admin interface to be able to set up new blog posts, you need to also register it. In the blogengine directory containing your app, create a new file called admin.py, and fill it out with the following code:

Once that’s done, return to the project directory and run this command to create the database tables you need:

python manage.py syncdb

You’ll get asked for some information to set up your user account - remember it as you’ll need it to log into the admin interface. Once that’s done, run python manage.py runserver again, and return to http://127.0.0.1:8000 again. You should be confronted with a 404 page - that’s fine, that’s exactly what we should be seeing. You’ll note that the message states that Django tried the ^admin/ path without success - what this means is that this is the only URL pattern in urls.py at the moment, and the path you entered didn’t match this.

If you change the URL in the browser to http://127.0.0.1:8000/admin, you should get a login screen. Enter the username and password you set when you ran syncdb and click Log in. You should now see Django’s admin interface, with Posts available, and an Add and Change dialogue visible next to it. If you want to add a few blog posts, just to have some data to work with, go ahead. Note that for the Date and Time dialogues, Django automatically adds the Today and Now shortcuts.

So, our model is now sorted and we have some data in the web app. The next step is to write our views. You’ll notice that the blogengine app contains a file called views.py - open this up and enter the following code:

Let’s go through this code. The first line imports the render_to_response method, which is used to render a template. The second line imports the Post model.

Next, we define the getRecentPosts view. For simplicity’s sake, we aren’t going to bother about pagination for the moment, so we’ll just get all the posts. The view is written as a Python function, and we pass it the request object as the sole parameter.

Next, we get all of the Post objects, using Post.objects.all(), and assign it to a list called posts. As we want these to be in reverse chronological order, we then reorder them by pub_date (note the - sign at the beginning to denote reverse order) and assign the result to sorted_posts. Finally, we load the posts.html template and pass through sorted_posts as the value in a dictionary called posts.

With our view done, we now need to produce a template for it. Head back up to your main project directory and create a new folder called templates. Then, go into settings.py and find the line marked TEMPLATE_DIRS. Inside the brackets, underneath the comments, add the full, absolute path to the new templates folder, as in this example:

"/Users/matthewdaly/Development/Python/Django/blog/templates"

You’ll have to change this to the full, absolute path on your machine. This will tell Django to look for the templates in that folder. Now, go into templates, and create a new file called posts.html. Enter the following text into it:

Most of this is just plain old HTML, but you’ll notice that {% %} denotes tags that can include some logic (such as a for loop in this case), and {{ }} denotes a variable. Remember that in the view we passed through a dictionary containing all of the Post objects, and here we’re iterating through all of those post objects, outputting their title, publication date and text content.

With this done, we need to configure the routes to call the getRecentPosts view when someone visits the home page. Open urls.py again and add the following code underneath where you enabled the admin, but still inside the parentheses:

# Home page
url(r'', 'blogengine.views.getRecentPosts'),

Now, this is a very simple regular expression. Here, this is our default page, so we leave the single quotes after the r empty. We then specify that this URL should be handled by the getRecentPosts function, inside views.py, in the blogengine application.

Save that, and start up the development server again with python manage.py runserver. Then, if you haven’t already added a few test posts, do so via the admin interface. Then open http://127.0.0.1:8000, and you should see your blog posts.

So, we now have the beginnings of a blogging application! We’ll leave it here for now, and will go on to add functionality like viewing individual posts and pagination later. We’ll also look into adding further functionality to our blog, such as supporting multiple authors, tagging posts, and adding flat pages.

]]>https://matthewdaly.co.uk/blog/2011/10/24/linux-in-the-workplace/
https://matthewdaly.co.uk/blog/2011/10/24/linux-in-the-workplace/Mon, 24 Oct 2011 21:18:12 GMTAt the start of September I left my customer services role and started a new position as a web developer. I won’t give the name of either my old or new employer, but I will say that the new role is with a much smaller company, and the part I work for now is an e-commerce store that enjoys a significant degree of independence from the parent company. There are only two developers including myself, and we are solely responsible for the company’s IT infrastructure, and we don’t have the hassle of dealing with legacy applications or infrastructure. We therefore have considerable freedom in terms of what we choose to use to get our work done.

When I first started, I used Windows XP Professional since that was what my work laptop came with, but it soon became obvious that there wasn’t actually anything I specifically needed to be using Windows for. I mostly work on the company’s intranet, which doesn’t really need to be tested in Internet Explorer as we use Firefox internally. For email and calendar, we use Google Apps, which works fine with virtually any email client that supports IMAP, so I was using Thunderbird with the Lightning plugin. When coding I used Netbeans with the jVi plugin for most of my work, with occasional usage of Vim for writing shorter scripts. I used AppServ to provide local versions of Apache, MySQL and PHP, and I used PHPMyAdmin to interact with the database. For version control, I used Subversion. From time to time I need to remote into another machine using VNC, SSH or RDP, for which I used mRemote, but I was confident I could find an equivalent application. Also, we use Ubuntu on most of our servers, so it made a lot of sense from a compatibility point of view to also use it on my own desktop. From time to time, I also found myself writing bash or Perl scripts for systems administration purposes, and since it wasn’t really very practical to do that in Windows when it was going to be running in Ubuntu, I’d used an Ubuntu Server install in Virtualbox to write it, but it was obvious that running Ubuntu as my desktop OS would make more sense.

As Ubuntu 11.10 was due a little over a month after I first started, I decided to hold off making the switch until then so I could start with the most recent version and not have the hassle of upgrading an existing install. I had already downloaded the 64-bit version of Ubuntu 11.10 for my home machines and burned them to a CD, so I brought the CD into work and set up a dual boot so I could revert back to XP if anything went wrong, and also so I could easily copy across any files I needed from the Windows partition.

It took a fair while to get everything I wanted installed, but a lot less time than it would have taken if I’d set up Windows XP from scratch. The hardware all worked fine out of the box, and most of the software I needed was in the repositories. The only thing that I really needed that wasn’t there was Netbeans (which has apparently now been removed from the repositories), but the version in the Ubuntu repositories has never been very up-to-date anyway. Instead I installed the version of Netbeans available on the website, and that has worked fine for me. While there wasn’t a version of mRemote available, I did discover Remmina, which has proven to be an excellent client for SSH, RDP and VNC, to the point that I’ve now stopped using the terminal to connect via SSH in favour of using Remmina instead. Thunderbird does just as good a job with my email and calendar as it does on Windows, and I also have Mutt available. Naturally, it couldn’t be simpler to install a full LAMP stack and PHPMyAdmin either. In fact, the only application that I use much that I couldn’t get a decent version of was MySQL Workbench, and that was only because Oracle haven’t yet released a version for Ubuntu 11.10 (tried the version for 11.04, but it doesn’t seem to work), but I can live without that.

What’s interesting is that despite all the scaremongering I’ve heard over the years about how Linux isn’t ready for the workplace, I’ve as yet had no problems whatsoever. For everything I used in Windows, it was either available on Ubuntu, or there was a viable equivalent, or I could get by fine without it. Granted, the nature of my work means I have little need for the small amount of functionality that Microsoft Office has and LibreOffice doesn’t, and I don’t need to use the kind of ghastly legacy apps written in Visual Basic that most large enterprises commonly use, but I haven’t noticed any significant barriers to my productivity.

In fact, if anything I’m considerably more productive. I know people like to rag on Unity, and I wasn’t happy with it in the netbook edition of Ubuntu 10.10 myself, but in 11.10 it’s really starting to show its promise, and I haven’t had any problems with it. The fact that I know Ubuntu a lot more thoroughly than I do Windows, purely from my own experience at home, means that I can get things done a lot quicker, but also the whole package management system means I’m largely free from the annoyances of opening an application in the morning to be confronted with an update dialogue, quite apart from the fact that very few updates require a restart. I’d go so far as to say that I’ve been more productive using Ubuntu at work than I would have been with either Windows 7 or OS X (and over the last few years I’ve used Windows Vista, Windows 7 and OS X fairly extensively).

I really don’t want this to turn into Yet Another Year of the Linux Desktop blog post, because that’s rather a tired old cliche, but I have absolutely no problems whatsoever getting my work done on Ubuntu. I’ll concede that as a developer I have significant freedom that isn’t often afforded to other people, and running some flavour of Unix makes a lot of sense if you’re a developer working with one of the open-source server-side languages such as PHP or Python (if I were a .NET developer, it would make rather less sense). I’m also lucky to be in a position where I don’t have to worry about legacy apps or IE compatibility too much. Nonetheless, it’s still remarkable how smoothly my migration across to Ubuntu on my work desktop has gone, and the extent to which I find it’s improved my workflow.

]]>https://matthewdaly.co.uk/blog/2010/07/05/five-things-you-should-consider-including-on-your-website/
https://matthewdaly.co.uk/blog/2010/07/05/five-things-you-should-consider-including-on-your-website/Mon, 05 Jul 2010 19:01:52 GMTIf you’re creating your first website, it’s tempting to think that once you’ve got the site looking the way you want it, and added some content, then that’s all you need to do. In reality, it’s extremely unlikely that this is the case. It’s fairly obvious with something like a blog that it needs regular care and attention, but even a static brochure site may need some additional resources to get the best out of it. Nowadays, there are loads of great resources around that you can use to enhance your websites, either for yourself or your readers (or both!) and knowing how to make the most of them can really make a difference in how well your site fulfills its intended role.

So here’s a list of five things you should consider including when you set up your first website that are easy to overlook, but can offer real benefits to both you and your users. Note that there’s more than a few Google tools here - this isn’t deliberate, it’s just that Google are so omnipresent in this area that it’s hard to get away from them.

A way to record visitor’s details - With most web hosts you can just look at the log files, but that doesn’t provide very much information at all, nor does it present it in a way that makes it easy to see the information you need. A much better idea is to use a dedicated web analytics service. I’ve used StatCounter in the past, but my favourite has to be Google Analytics. Both give you access to a great deal of useful information about your website. For instance, you can see how many people view the site in Internet Explorer 6, so you can figure out for yourself whether it’s worth bothering to adjust for IE6 when you redesign the site next. Or you could see how many people view the site in a mobile browser. You can also see what pages are popular, how long people remain on your site, and how they got there in the first place. All this is extremely useful information that can give you good ideas as to how to improve your site.

A comment system - OK, this is blog-specific, but comments mean you can gauge reader interest levels, and encourage more reader participation, so having a good comment system is essential. Most blogging engines have an OK comment system, but there are a few dedicated comment systems you can install on your blog that offer a lot more features than the default system. For instance, my blog uses Disqus in preference to the default WordPress comment system, because I find it’s far more flexible and powerful. It offers threaded comments, as well as support for readers logging in via Twitter, Facebook, Yahoo!, OpenID or Disqus, which means they can use an existing account to submit their comment rather than having to go through the rigmarole of signing up, which can dissuade people from commenting. Also, it offers fine-grained control of moderation and spam, such as allowing you to blacklist or whitelist commenters, automatically accept comments unless they include a link (very handy for tackling spam comments), and many other useful tools. I’ve also heard good things about IntenseDebate.

RSS feed management - If your site has an RSS feed, you should seriously consider using Feedburner. It’s a great tool that allows you to present your site’s RSS feed in an extremely pleasant way that makes it extremely easy for readers to subscribe using whatever feed reader they like, or by email (always worth having because it’s ideal for people who don’t know what an RSS feed is). It also allows you to add easy ways for users to share your content from within the feed, or for you to add Google AdSense to the feed itself if you wish.

A way to share content - Again, this is more blog-specific than something suitable for a static site, but you should make it easy for people to share posts they like with friends or submit them to social bookmarking sites. It’s probably to your benefit to do so since this will not only send more traffic to your site, but will mean you gain additional links to your site, improving its ranking in Google searches. Some WordPress themes include a way to share content, but other themes, or different blogging engines, may not offer this so an alternative way to share is helpful. In particular, I can recommend AddThis as a good choice.

AdWords - If your site is something you’re hoping to make money from (such as an e-commerce site, or you’re hoping to attract people there to hire your services), then it makes sense to advertise. While I don’t wish to sound like one of those self-appointed “social media experts” who haunt Twitter, you do need to make an effort to get your name out there, and Google AdWords is a really great way to do that cheaply and easily. You only need to pay when someone clicks on an ad, and they only show up in relevant places.

What other services would you recommend using with a new website?

]]>https://matthewdaly.co.uk/blog/2010/06/22/exam-tomorrow/
https://matthewdaly.co.uk/blog/2010/06/22/exam-tomorrow/Tue, 22 Jun 2010 14:57:11 GMTJust a short note to say that tomorrow morning I have my CIW JavaScript Fundamentals exam. Hopefully I should be able to pass first time (although I’m not impressed by how inaccurate the practice exams are, and how out of date the training materials are), and should then be able to get on with learning Perl next. I’m looking forward to learning Perl, as it’s more the kind of thing I’m interested in than JavaScript is.
]]>https://matthewdaly.co.uk/blog/2010/06/18/why-is-chrome-so-popular-all-of-a-sudden/
https://matthewdaly.co.uk/blog/2010/06/18/why-is-chrome-so-popular-all-of-a-sudden/Fri, 18 Jun 2010 21:12:40 GMTI don’t know how or when it happened, but suddenly I’ve noticed that a hell of a lot of people I wouldn’t normally expect to pay much attention when someone nags them to update their web browser are using Google Chrome. Non computer-savvy work colleagues are using it, and even my father has dumped Internet Explorer 8 in favour of Chrome - yet he wouldn’t consider Firefox despite my years of virtually begging him to switch!

In May 2010, the statistics on W3Schools.com are quite telling. Google Chrome makes up 14.5% of the hits on the site, which is higher than either IE6 or IE7 - IE8 is the only version of Internet Explorer that’s still ahead. Chrome is still behind Firefox, which takes up a huge 46.9% of the hits, but it’s not bad for a browser that’s been out for less than two years. More notably, Chrome has increased its market share by around 5% in the last six months, while IE6 has declined by a little over 3%. Granted, W3Schools is likely to be frequented mostly by web professionals who use more modern browsers, but in terms of the decline of IE6 at least, they’re backed up by Statcounter, who have reported that IE6 usage has fallen below 5% for the first time.

This can’t be a bad thing - Chrome’s one of the fastest and most standards-compliant browsers around and has some of the best support for HTML5 and CSS3, as well as fast and efficient execution of JavaScript. It also has one of the best security records of any modern web browser - it’s consistently been the only desktop web browser to survive the Pwn2Own contest unscathed.

But why is this happening? Accepted wisdom for some time has been that non-technical users just use whatever browser comes with their computer, thus giving IE a huge advantage, but the increasing popularity of Chrome runs counter to this, so it’s clearly more complex than that. So much of its growth has been very recent that I don’t think it’s likely to be technically adept users, many of whom are already attached to Firefox or Safari (I still use Firefox sometimes myself, although for most things I’ve switched to Chrome).

I think part of the reason is the fact that Google are dropping IE6 support on their sites, particularly YouTube, which is a hugely popular site, thus forcing people to ditch IE6 for something else. Naturally, Google provide links to download Chrome on the site, so maybe people are just going for the first alternative they see that will work.

Have you noticed this? Why do you think some non-technical users are switching to Chrome when they wouldn’t switch to Firefox?

]]>https://matthewdaly.co.uk/blog/2010/05/15/is-dreamweaver-the-best-choice-for-developing-your-first-website/
https://matthewdaly.co.uk/blog/2010/05/15/is-dreamweaver-the-best-choice-for-developing-your-first-website/Sat, 15 May 2010 16:27:49 GMTIf someone asks you to name an application for creating web pages, the chances are that one of the first things you’ll think of is Adobe Dreamweaver. While it may not have quite as much mindshare as its Creative Suite stablemate Photoshop, it’s still regarded as the premier application for creating web pages.

However, that status leads to many novice developers, or ordinary people who just want to set up one website, thinking that they need to use it, and that’s completely wrong. At work we have an intranet with a discussion forum, and someone with no experience of creating web pages was asking for advice on the best application to use to create a website, and of course someone suggested Dreamweaver, something I strongly disagree with.

So, if you’re wanting to build a basic website, and are thinking Dreamweaver might be the way forward, you might want to bear these points in mind:

HTML was intended right from the start to be reasonably easy to use, so why not just write HTML? I learned the basics in a weekend, and there’s plenty of good resources around, so rather than shell out for a copy of Dreamweaver, just get a book about it and work through that. It’s a useful skill to know and it costs a lot less, and the resulting web page will be easy to maintain. Granted it may not be that impressive to start with, but there’s nothing stopping you refining it over time.

You probably don’t need to mark up web pages yourself at all. There are many excellent content management systems that make it easy to build a website yourself without having to write any HTML or CSS at all. Wordpress is capable of static pages and blogs, is easy to theme, and can be extended with plugins. Drupal or Joomla are also possibilities, so the chances are it’s not necessary to hand-code the page at all.

If you’re only after a basic site and you don’t have any interest in creating any other web pages, but you want something that looks professional, then forget Dreamweaver and hire a freelance web designer to create the page for you. For a small site they’ll probably cost less than buying a copy of Dreamweaver, they’ll be able to create a much more professional-looking result and they’ll be able to help you with other issues that arise.

Is it the most cost-effective WYSIWYG editor for what you want? The world is full of WYSIWYG HTML editors, many of which are free, others of which are a lot cheaper than Dreamweaver. Okay, you could just use a trial version of Dreamweaver for free, but what about if you want to edit your site later on after your trial has expired? And yes, you probably could use a pirate copy, but is it really worth the bother when something else will probably do the trick? Some great alternative HTML editors include:

There are many more cheap or free HTML editors around, which make great alternatives to Dreamweaver for inexperienced users.

Dreamweaver is a powerful tool, but it’s not a magic bullet - it won’t make you able to create a great website, any more than a copy of Microsoft Word will make you a great writer. Dreamweaver’s a professional application, with a price tag to match, and it takes experience to use it properly. In the hands of an experienced web professional, Dreamweaver can create a great website, but in unskilled hands the results are going to be less than satisfactory.

What do you think? Is Dreamweaver a good choice for making your first (or indeed only) website, or not?