Zuhlke Engineering is hosting a corporate networking event at Canada Square on the 20th November. There will be an informative one hour presentation, followed by lunch and a networking session.

Here is a short snippet from the leaflet:
Zuhlke will share thier experience in successfully helping CIO’s and Programme / Project Managers in Top Tier Banks and other Corporates to:

• Get the business on your side by capturing requirements in their language but with the precision you need
• Win the battle for budgets, ensuring the right level of project funding throughout
• Get compliance and audit without the pain
• Corner suppliers into delivering only high quality software

The speakers at the event are:
Prof. Dr. Wolfgang Emmerich (Chairman, Zuhlke UK)
Wolfgang is a Partner in the Zuhlke Technology Group of Switzerland. He was also co-founder of Zuhlke Engineering GmbH, Germany in 1998 and Zuhlke Engineering Ltd, London in 2001, where he is currently Chairman and part-time Principal Consultant, primarily to the investment banking sector.

Keith Braithwaite (Head of Zuhlke’s Centre for Agile Practice)
Keith is a Principal Consultant and Business Unit Leader with Zuhlke in the UK. He has trained, coached and managed development teams from New York to Sydney working on systems ranging from mobile telephone applications to enterprise scale financial systems. He is a regular presenter at conferences around the world.

This is a free event and seats are limited. If you would like to attend this event then please contact me.

Regards, Daryn

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

5. Development and Debugging Tools

5.1. Documenting JavaScript

JSDoc is an open source tool used to add inline documentation to JavaScript source files.   JSDoc is based on the javadoc tool.   Many of the javadoc characteristics have been included in JSDoc.   An example of using JSDoc can be found here.

5.2. Firefox Tools & Extensions

DOM Inspector is included in the Mozilla Suite and Firefox browser.   This tool provides a graphical user interface that enables a user to brows the document object model of any site.   One can view, update and insert DOM attributes dynamically.   In order to assist JavaScript developers, DOM Inspector can be switched to JavaScript Object mode.   This shows all the properties and methods available to a JavaScript for a particular mode.   DOM Inspector provides a JavaScript evaluation window that allows the user to execute JavaScript against selected nodes.   There is the option to use CSS Style Rules and Computed Style information.   This allows a user to examine the CSS attributes associated with different page elements.

Firefox JavaScript Console is a tool that logs JavaScript errors found on a page when the page is rendered.   The Firefox JavaScript Console gives ‘compiler-type’ messages.   It describes the error that occurred and the gives the line number.

Firebug integrates with Firefox and provides many development tools.   Firebug has a version of a DOM inspector that enables a developer to find elements.   CSS support allows settings to be altered and viewed.   Firebug allows one to monitor the network activity in order to determine how long it takes for different sections of a page to download.      A JavaScript Debugger allows one to debug and step through the JavaScript at runtime.

HTML Validator is a Mozilla extension that performs HTML validation within Firefox and Mozilla.   HTML Validator validates the HTML locally and does not use a remote third party.   The number of errors of a HTML page is seen on the form of an icon in the status bar when browsing.   HTML Validator offers a set of tools to assist in validating and correcting HTML tags.

Checky is Firefox extension tool for validating HTML.   In addition to HTML, Checky can validate XHTML, CSS, RDF, RSS, XML and many more formats.   Checky sends the source to third-party cites to be validated.   The third-party cites may be free or commercial services.

Pederick’s Firefox Web Developer extension offers a large set of tools for a website developer.      Web Developer provides an extensive set of tools, from highlighting table cells to converting ‘GET’ requests to ‘POST’ requests.   This toolbar contains more than 80 tools and is an essential commodity.

5.3. JavaScript Syntax Checking

JSLint is an online tool that evaluates JavaScript code.   JSLint scans the JavaScript code and identifies syntax errors, structural problems and questionable coding-style conventions.

5.4. Compression and Obfuscation

MemTronic’s FREEWARE HTML/JavaScript Cruncher-Compressor  is a freeware tool that can perform both compression and obfuscation.   The MemTronic’s website provides the following information.   The tool can Crunch, Compress and Obfuscate.   Crunching removes all comments and whitespace.   Crunching has a bandwidth saving between 20%-50%.   Compressing will compress the script with a real compression-scheme, with auto decompression added to the file.   This results in bandwidth savings between 40% – 90%.   The obfuscator has not been released at this stage.   Once complete this tool will encode the script into a format that humans can not easily read.   When using Compress, the file will undergo a level of obfuscation.

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

Posted in AJAX, Technologies Tagged: AJAX, JavaScript, Tools ]]> http://darynholmes.wordpress.com/2008/09/23/ajax-fundamentals-part-4/feed/ 5 Daryn http://darynholmes.wordpress.com/2008/07/12/ajax-fundamentals-part-3/ http://darynholmes.wordpress.com/2008/07/12/ajax-fundamentals-part-3/#comments Sat, 12 Jul 2008 08:39:01 +0000 darynholmes http://darynholmes.wordpress.com/?p=86 ]]>

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

3. Security Issues

The XMLHttpRequest object is restricted to run within the browser’s security sandbox. Any resources requested by the XMLHttpRequest object must reside within the same domain from which the calling script originated. Therefore the XMLHttpRequest object is constrained to requesting resources that reside within the same domain from which the script was originally served. The W3C states, that in the future The XMLHttpRequest Object specification will define a way of doing cross-site requests.

There is an overabundance of online documentation stating that Ajax introduces multiple security threats. These threats include fake requests, denial of service, cross-site scripting (XSS), reliance on client-side security, and more. Jeremiah Grossman’s article, Myth-Busting AJAX (In)security, maintains that these security issues existed before Ajax and the recommended security best practices remain unchanged. Part of internet security basics is to distrust the client. Ajax is a client side technology and requests need to be treaded with the same caution as all other calls.

4. Disadvantages

4.1. Usability Problems

Web users have become familiar with using classic web pages. Users have become accustomed to using browser features such as the back and next buttons. Ajax calls are not loaded onto the browsers navigation stack. Therefore the back button will not undo the last ‘Ajax operation’. Developers need to explicitly cater for undo operations.

Ajax enabled pages have a notion of state; this state is altered as the user navigates through the site. The browser is unaware of this state, and it is not reflected in the address bar. Therefore users are not always able to book mark a certain page state. Developers need to consider this when deciding on when to use Ajax.

The asynchronous nature may make page updates difficult for the user to notice. The developer needs a way of drawing the user’s attention to the modified section of the page. The ‘yellow-fade technique’ has become common practice. In this technique the changes are highlighted with a yellow background, and the yellow fades gradually. These and other techniques are becoming familiar to web users.

4.2. JavaScript Disabled

If a user has disabled JavaScript no JavaScript will be executed and certainly no Ajax requests will be sent. A site that relies too heavily on JavaScript will be crippled if the user disables JavaScript, Gucci is an example of this. This site used to show a blank white page if a user browsed to it after disabling JavaScript. Now it explains that you need to have JavaScript enabled to use the site.

A site that relies on JavaScript for core functionality restricts its users to those who have JavaScript enabled. Having said that we should look at how many users are allowing JavaScript to run in there browsers. The following statistics from The Counter show JavaScript statistics.

Wed Mar 1 00:01:01 2000 – Fri Mar 17 23:59:01 2000
Javascript 1.2+: 260153365 (79%)
Javascript <1.2: 7790575 (2%)
Javascript false: 59884983 (18%)

Thu Mar 1 00:01:01 2007 – Thu Mar 22 13:58:01 2007
Javascript 1.2+: 56607094 (95%)
Javascript <1.2: 193622 (0%)
Javascript false: 2524217 (4%)

These stats show that most users are using JavaScript, therefore many stake holders would approve of the use of Ajax on their sites. Although there are cases where limiting access is unacceptable.

4.3. Search Engine Indexing

Web crawlers automatically navigate through the web by following link tags e.g. href, src etc. Current web crawlers do not examine client side scripts. Search engines skip the JavaScript code that executes the Ajax calls. Content loaded by Ajax calls will not be indexed by search engines.

Multiple solutions have been proposed to solve this problem. Most of these are workarounds and do not solve the underlying problem. In fact some approaches are considered as cloaking and can get the site black listed by Google. Google have stated that they will improve there searches, at present they do not follow Ajax calls. In order to make sure that specific content will be found by search engines, the site should have standard HTML links that web crawlers can follow.

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

]]> http://darynholmes.wordpress.com/2008/07/12/ajax-fundamentals-part-3/feed/ 5 Daryn http://darynholmes.wordpress.com/2008/07/10/private-thinking-in-rails-%e2%80%93-part-1/ http://darynholmes.wordpress.com/2008/07/10/private-thinking-in-rails-%e2%80%93-part-1/#comments Thu, 10 Jul 2008 15:55:50 +0000 darynholmes http://darynholmes.wordpress.com/?p=79 ]]>

Part 0

In this part we look at the basic set of requirements for our text editor. I have no doubt that these requirements will change, but let’s have a quick look to get an idea of the direction we are heading in.

Text Editor Requirements

As mentioned in part 0, the text editor is going to be a very basic editor. It will maintain a version history that will allow users to roll back to a previous version of a document. This requirement is what will make this task interesting and worthwhile.

We would like to end up with screens similar to this:

The documents index page:

Clicking ‘show’ will show the related document and give the user an option to edit it.

Clicking ‘edit’ will show a form that allows the user to edit the document. When the user clicks ‘save’, the application creates a new version, without overwriting existing versions.
We will be providing this behaviour with a slight ‘twist of hand’. I will come back to this point when we actually implement it.

Clicking ‘delete’ will completely remove the document and all its versions – this is not a roll back.

If the user clicks on ‘History’ on ‘Second one’. We expect to see a screen similar to this:

Clicking ‘show’ will show the relevant version.
Clicking ‘rollback’ will delete the latest version, thus rolling back to the previous version – this is deleting one version only, not the entire document.

What is next?

Next we will have a quick look at the database schema and then we finally move onto Rails code! We will not be using the scaffolding features of Ruby on Rails. We will create our application from the ground up – generating models, controllers and views independently. We will also be coding using TDD. If you are new to Rails, I am sure you will enjoy the upcoming posts.

Part 1

This is ‘part 0’ as it is an explanation of the tutorial, no Rails code is covered in this part – I still need to write the code. This post explains what you can expect to see in future parts of this tutorial. If there is a topic you would like me to cover then please feel free to make a request…

What is the purpose of this tutorial?

Ruby is not just another OOP language. It has many idioms and constructs which seem foreign at first. Once a developer becomes familiar with these aspects the developer tends to program in a new way – the once foreign code starts to feel very natural.

Moving from Java or .Net to Ruby (and Ruby on Rails) is a challenge, but it is worth the effort. Once you start thinking in the Ruby and Rails way code starts falling into place. To cross the conceptual chasm you need to read many articles, books and as much code as you can. This tutorial aims to assist you as you crossover. Use it as a stepping stone on your path to the land of the ducks.

How did this tutorial come to be?

This tutorial is a spin-off from the ‘Routing in Rails’ tutorial. The ‘text editor’ application covered here was originally intended to be the practical section of part 6. I started developing the application and soon realised that the actual routing work was very small, and was being lost amongst the rest of the code. I felt that the application still covered many useful topics, therefore I decided to move it into its own tutorial – and here it is.

What does this tutorial cover?

This tutorial attempts to answer two questions posted to me in previous comments and emails. One question was with regards to one to many relationships and nested resources. This was covered in part 6 of the ‘Routing Tutorial’ – here we use them to build the ‘text application’ below.

The second question was from Tom made here: “When you get to RESTful routing I would like to see an example of how to add a Save As function. This would allow the user to derive a new record in a table from an existing record. So it would start as an edit function but end as a create action instead of an update action”

The second question poses an interesting REST problem. Some readers may not agree with the solution I am suggesting here. If you have any objections to this solution, please voice your objection in a comment, this will help all of us.

In addition to answering these questions, this tutorial will cover some common Rails problems e.g. using 2 models with 1 form, has many function, YAML, testing in Rails, replacing link_to with button_to etc.

As you can see, this tutorial covers many topics. I do not intend to cover each topic in detail – I would like to, I just don’t have the time. The ‘Rails Routing Tutorial’ focused on one specific topic. This tutorial shows you a bigger picture; the aim is to help you to start thinking in Rails.

What is not covered in this tutorial?

We will not be creating the definitive Rails application. The application being developed here should be thought of as the output of iteration one. While following along you should find yourself thinking: ‘would it not be better to do this?’, ‘if we did this, the test would be much cleaner’, ‘I wonder if we can add this information to the view’. If you start thinking like that, then you are starting to think in the Rails way.

Even though it is a good idea to add CSS to your Rails application from a very early stage, I do not intend to cover CSS. I would rather focus on other topics, at least for the first few parts of this tutorial – I may include it at a later stage.

This tutorial will cover the default Rails testing and not RSpec. RSpec is good and I recommend that you look into it. The only reason I am not using it here is because it requires plug-ins. These plug-ins are version dependant and I would rather avoid the potential versioning conflicts that may result from this. The testing lessons learned here can be carried over to RSpec.

What about the Music Store?

In this tutorial we will not be using the amazing Music Store application from the Routing tutorial. Instead we can create a new application. This new application will be a plain text editor. The text editor will have a version history. This will allow a user to ‘roll back’ to a previous version of the document.

This will be a basic text editor. The intension is not to create a fully fledged text editor. The aim is to familiarise ourselves with the Rails development process so that we begin to think in Rails.

What is next?

Next we look at the basic set of requirements of the text editor application. Please let me know if you would like to know more about a specific Rails topic, I will try to work it into the tutorial.

About a week ago I noticed some incoming links from Computer Weekly.com. I assumed that someone had commented on one of my posts, so I browsed there wondering if it was a positive or negative comment. Once the page loaded, I was completely surprised. It turns out that this blog has been short-listed for the Computer Weekly.com IT Blog Awards! This came as a complete surprise to me.

This blog had really humble beginnings. In fact it was not even my idea to start a blog, it was my work that encouraged me to start one. Initially I felt that I did not have that much to contribute to the world at large. In fact I still don’t feel that my blog is as innovative as some others, although judging by the response to my ‘Routing In Rails Tutorial‘ it appears as if I do have a nice way of explaining things. I guess this is one of the main reasons I have been voted onto the shortlist.

The competition ends on the 31st of July 2008. If you would like to vote please go to this on-line voting page. This blog can be found under the ‘Programming and technical blogs’ drop-down list. It is a surprisingly painless exercise, it takes less then a minute and no registration is required.

Thank you to all of you who have voted for this blog.

Daryn

In part 5 we looked at RESTful routing. In this part we continue to explore RESTful routing, by examining nested resources.

I originally planned to cover nested routes and to cover two questions posted to me in previous comments and emails. One question was with regards to ‘one to many relationships’ e.g. an album has many songs. The second question was from Tom in part 3; this was about adding save as functionality.

In trying to answer these questions I created a new application – a text editor with a version history. This has turned out to be a fairly interesting piece of work. I then changed my mind and decided to include it in a follow up post. I am hoping to have that out later this week (before Friday the 11th of July).  As the ‘follow up’ post will have a practical example of nested resources, this post will not have the usual practical section with the experiments.

Part 6

Introduction to Nested Resources

The Nested URI

Returning to the familiar Music Store application, imagine we added songs to the application. Like Albums, Songs are resources and we could expect to access a song with this URI:

/songs/124

We could then perform the required CRUD operations on that URI based on the REST API as discussed in part 5.

An album has many songs. We can express this within the URI e.g.

/albums/10/songs/124

Once again we could make use of the HTTP verbs to perform CRUD in a RESTful way.

In this particular implementation, this URI does not mean that this is the 124^th song of album 10 - it is possible for it to be the fist song of album 10.  The URI is pointing to the 124^th song in the system.

If we wanted the URI to state the song\track number of the specified album then we could alter the above implementation. Then we could expect to see URIs of:

/albums/10/songs/5
and
/albums/11/songs/5

This would not result in a URI conflict.

Implementing Nested resources in Rails

If we decided to add songs to the Music Store application, we could start off by aiming for a URI of:

/songs/124

As you may recall, we can achieve this by declaring this resource in the routes.rb file:

map.resources :songs

This will give us access to helper methods such as songs_url, song_url (@song) etc. This was discussed in part 5 under ‘Experiment 5.2 Showing the Index Page’.

Next we could aim for a nested URI:

/albums/10/songs/124

To achieve this we use the following construct:

  map.resources :albums do |albums|
    albums.resources :songs
  end

Note that it is albums.resources :songs and not map.resources.

With this routing rule, Rails will generate slightly different helper methods. To view these routes we could use the method described in part one. There is also a more convenient rake task: rake routes.
This is one of the ‘things’ I have been meaning to mention. You may have read it in a previous comment.

If you use ‘rake routes’ you will notice that there are a quite a lot helper methods being generated, more than the 7 I pointed out in part 5. The ‘extra’ methods are there to create URIs for different formats.

Below is filtered output from ‘rake routes’

 album_songs 		GET    	/albums/:album_id/songs	            {:action=>"index", :controller=>"songs"}
 			POST 	/albums/:album_id/songs             {:action=>"create", :controller=>"songs"}
 new_album_song	 	GET   	/albums/:album_id/songs/new         {:action=>"new", :controller=>"songs"}
 edit_album_song	GET    	/albums/:album_id/songs/:id/edit    {:action=>"edit", :controller=>"songs"}
 album_song 		GET    	/albums/:album_id/songs/:id         {:action=>"show", :controller=>"songs"}
 			PUT    	/albums/:album_id/songs/:id         {:action=>"update", :controller=>"songs"}
 			DELETE 	/albums/:album_id/songs/:id         {:action=>"destroy", :controller=>"songs"}

As you can see, we now have helper methods which look like album_songs_url and album_song_url(@song). The path versions are also available.

Inside the view we could have:
link_to ‘Edit’, edit_album_song(@album, @song)

Looking at the rake routes output above, we can see that the songs controller can get access to the album ID via params[:album_id]. The song ID can be obtained using params[:id].

Now we have helper methods that generate URIs of the form:

/albums/10/songs/124

Our routing system also knows how to deal with incoming URIs of that form.
Now we would like an implementation that allows us to use URIs like:

/albums/10/songs/5

Where song 5 really is the 5th song in album 10. Therefore we could have:

/albums/10/songs/5
and
/albums/20/songs/5

As with most things, it is easy once you know how. To achieve this we simply need to override the ‘to_param’ method in the song model. I imagine that would look something like this:

def to_param
number # number is the track number of this song on the album
end

After this change we would need to modify the controller as params[:id] would return the song number and not the song id. The controllers would need to use

@song = Song.find_by_number(params[:id])
and not
@song = Song.find(params[:id])

There will be more on this in the follow up text editor post.

Deep Nesting

Jamis Buck recommends that resources should never be nested more than one level deep. You can find his original post about that here. The Rails community seems to be divided about this ‘rule of thumb’. I recommend that you follow this guideline – although remember it is just a guideline, you can use deeper nesting if the need arises.

End of Part 6

This was a quick and short introduction to nested resources. There is a bit more to them, but this enough to start writting Rails applications.

In the follow up, ‘plain text editor’, post we will see a nested route being used a slightly larger application. In that post we will look far more than just routing, that is why I took it out of this part. I will finish that up ASAP.  I hope you have enjoyed this post…

- Thank you, Daryn

Over engineering is a major problem within the software industry. This problem has led to the adoption of ‘lean software development’ – at least amongst the agile folk. Lean software development is writing code to support the current set of requirements and nothing more. This is not as easy to do as one might think.

As developers we naturally tend to make assumptions as to what the user, or system, will need. In truth, it is very difficult to accurately predict the future requirements of a system. Coding to meet our assumptions will inevitably lead to over engineering.

We should not let our intuition guide us into false requirements. As strange as it may sound, it takes a concious effort to stop ourselves from doing extra work. We need to adopt a ‘lean coding culture’. We need to constantly remind our selves to stick to lean software development. In agile teams it is common to hear developers reminding each other with certain acronyms and expressions e.g. ‘do the simplest thing that works’.

‘Do the simplest thing that works’ is in-line with lean software development, although it can be misleading. Some people interpret this as ‘do the first thing that comes to mind’ e.g. slap on another if statement – that is a simplistic solution and not a simple solution. If you take a quick and dirty simplistic approach you will end up with a big ball of mud. You need to do the simplest thing that works. The thing that works is something that can be tested, it is something that does not add unnecessary complexity. Therefore the simplest thing that works is not necessarily the quickest and easiest thing to do.

When talking about lean software development we often refer to KISS (Keep It Simple Stupid). I agree with keeping things simple but I don’t like to be called stupid, the truth hurts. I prefer to use: Keep It Simple and Sensible. This is more positive and the sensible part indicates that we should give some thought to our code. For example, instead of littering your code with conditional statements you could refactor the code to use an established design pattern. Having said that, design patterns are not always a good idea.

You should not implement a design pattern unless there are real signs indicating that you need a smarter solution. It can be detrimental to implement a design pattern for the sake of having one. You are likely to implement the wrong pattern and that code will be a hindrance. Only do what you really need to do. This is also referred to as YAGNI.

YAGNI (You Ain’t Gonna Need It) – This is a term used by Russ Olsen in Design Patterns in Ruby. In this book, Russ Olsen does a fantastic job of explaining design patterns. He also explains when not to use certain patterns and the problems that come with using each pattern – After all, software is about trade off’s.

Russ Olsen explains that we should not write code or implement patterns in anticipation of a requirement that might emerge. Firstly that requirement may never surface, and if it does it may have a stipulation which makes the pre-emptive solution void. It is safer to code to meet the current and real requirements of the system. To drive this point home, here is a delightful paragraph from Russ Olsens’ Design Patterns in Ruby:

“Look at it this way: Barring a sharp blow to the head, as you stand here today you are as dumb as you ever will be. We are all learning, getting smarter every day. This is especially true in software projects: You can be sure that you will have a better grasp of the requirements, technology, and design of any software that you work on at the end of the project then at the beginning. Whenever you put in a feature before you really need it, you are guilty of programming while stupid; if you wait until you really do need the thing, you are likely to have a better understanding of what you need to do and how you should go about doing it.”

The moral is: Don’t be guilty of programming while stupid

Part 6

In part 4 we explored named routes. In this session we move onto Rails’ REST.

Part 5

The Critics

Before we begin you should know that there are many critics of the Rails implementation of REST. There are many reasons for arguments against Rails’ REST e.g. Rails uses server side session state and client side cookies. Some people say that this is not REST compliant. Rails’ REST might not be 100% REST compliant, but you can still benefit from using REST in your Rails applications. In The Rails Way, Obie Fernandez explains that the benefits from using Rails’ REST fall into two categories:

• Convenience and automatic best practices for you
• A REST interface to your application for the rest of the world

Therefore it is worth learning and using Rails’ REST.

The Standard Introduction

Representational State Transfer (REST) is an architectural style. It was first introduced by Roy Fielding in his PhD thesis. Roy Fielding is one of the principal authors of HTTP.

The Mindset

When developing a Rails application in the RESTful way it helps to change your mindset. You should not think that you are developing a web site for users accessing the site via a browser. It is better to think of the application as being a service. The service performs actions for clients. These clients may be humans or other machines on the network.

This service will typically be placed on the internet. Therefore we could call it a web service. When I hear the term web service I immediately start thinking about SOAP and all the WS-* specifications. Let’s be clear, we are not talking about ‘those’ web services. We are talking about RESTful web services. These two technologies provide similar functionality, but RESTful web services are simple and sensible.

The Terminology

As previously stated, programming in REST requires a change in the way we think about the system. This naturally leads to a change in the way we talk about the system. The following provides a brief description of some of the key terms used in discussions about REST and HTTP.

A resource is one of the key concepts in REST. Many discussions on REST claim that a resource is anything and everything. This is neither true nor helpful. Let’s examine this concept with the aid of an example.

Let’s assume that the music store has started selling albums. The database may have the following schema:

The data in the database is the raw data. There is data which, given in isolation, is of no real value to a client. For instance it is unlikely that a client will want only one row from the LineItems table. This means that a LineItem (on its own) is not a resource within the context of the music store service.

A client would want all the information pertaining to an order. This would include data from one or more tables. Some data would not be included e.g. database keys. Some information may be added e.g. the total cost of the order might be calculated and included in the ‘order information’. This ‘order information’ is an example of a resource. Order resource is the type, there will be one order resource instance for each order made.

Each resource must be given a globally unique identifier. This is done using a URI. This could look like this:

http://www.example.com/orders/65

A client, in an admin role, may want a list of all the orders. This collection of orders would be another resource. Following the REST architecture, the orders resource would be assigned the following URL:

http://www.example.com/orders

It is important to note that these resources are not HTML documents. Roy Fielding describes a resource as a conceptual mapping. As a resource is a conceptual entity it can not be used by a client. The service provides the client with a representation of the resource.

When the client is a browser, the service typically provides an HTML representation of the resource. If the client is another machine then the service may provide an XML representation of the resource. Other representations could include a PDF file, an image, csv etc. A representation is only supported by the service if it is applicable and required.

Resources are often referred to as nouns. This is often done when talking about HTTP to assist learning. The term ‘noun’ is more abstract. For our purposes, resources and ‘nouns’ are synonymous.

HTTP also has the notion of verbs. These are the HTTP operations. We are all familiar with the POST and GET operations. In addition to these two operations, HTTP also supports: DELETE and PUT.

There are a few more terms to cover, but we can do that later. The core terms have been explained.

Joining The Dots…

REST is an architecture style which makes full use of HTTP. Some say that it makes proper use of HTTP.

As previously explained, HTTP supports GET, POST, DELETE and PUT. One of the main ideas behind REST is to use these HTTP operations to determine the correct action to perform. Let’s clarify this with an example.

If the RESTful music store server receives a URL of: /albums/4 sent with a GET, then the server will invoke the show action of the albums controller. The response may be an HTML page showing details of the 4th album.

If the server receives a URL of: /albums/4 sent with a DELETE, then the server will invoke the destroy action of the albums controller. This will result in the 4th album being deleted.

Note that the URL did not contain explicit ‘show’ or ‘delete’ information. The server was able to infer the action by examining the HTTP operation. Therefore show and delete were implicitly called.

The form of that URL is REST compliant. If the music store had to include Artists and Songs, we could expect to see URLs like this:
/artists/2
/songs/8

As you can see a consistent API is forming, this is the REST API. It becomes intuitive once you start getting familiar with it. For instance I am sure you can tell what would happen if we did a DELETE on this URL:
/songs/154

An application typically performs the full set of CRUD operations – Create Read Update and Delete. The following table shows the mapping between database CRUD operations, the HTTP verbs, and REST compliant URLs.

When creating a new album, the plural /albums is used. This is because we are adding a one new album to the collection of albums.

In previous posts in this series, creating and editing an album has always involved two controller actions being invoked. When we create an album we:

1. Call the new action to retrieve a form with empty fields
2. Call the create action which creates a new album extracting the information from that form

When doing an update we:

1. Call the edit action to get a form with fields filled in with data from the relevant album
2. Call the update action which then performs the actual database update

This is the typical behaviour of a website. We need to fit this behaviour in with REST. When doing an edit we can’t obtain the albums details by doing a GET on /album/1 – that is already used for showing an album.

This functionality is achieved with modifiers (also called adjectives). The modifiers we need are ‘new’ and ‘edit’. This results in the following mapping:

Note the last line which calls the index action.

As you can tell, we are moving towards Rails specific terminology. I guess this means it is time to step into the code…

Experiment 5.0 Preparation

In part 4 we created named routes. The routes.rb file looked like this:

ActionController::Routing::Routes.draw do |map|  

 map.albums 'albums',
 :controller => "albums",
 :action => "index"

 map.album 'album/:id',
 :controller => "albums",
 :action => "show"

 map.edit_album 'albums/:id/edit',
 :controller => "albums",
 :action => "edit"

 map.update_album 'albums/:id/update',
 :controller => "albums",
 :action => "update"  

 map.destroy_album 'albums/:id/destroy',
 :controller => "albums",
 :action => "destroy"     

 map.new_album 'albums/new',
 :controller => "albums",
 :action => "new"  

 map.create_album 'albums/create',
 :controller => "albums",
 :action => "create"  

 #map.connect ':controller/:action/:id'
 #map.connect ':controller/:action/:id.:format'

end

In this session we move from named routes to RESTful routing. Therefore we can delete these named routes. Empty the routes.rb file:

ActionController::Routing::Routes.draw do |map|  

 #map.connect ':controller/:action/:id'
 #map.connect ':controller/:action/:id.:format'

end

Once again we have a broken music store. Let’s fix it and make it REST compliant.

Experiment 5.1 Including REST Routes

We want the music store application to be REST compliant. At the moment we don’t make use of the HTTP operations, instead we explicitly state the intentions within the URL. At the end of part 4 the site worked like this:

The application was fairly similar to REST. This is because the named routes created in part 4 were based on the REST style. To make the application more RESTful we need to make use of the HTTP verbs. We could update each of our named routes to explicitly state the HTTP operation e.g.

  map.albums 'albums',
    :controller => "albums",
    :action => "index",
    :method => "get"
 

Rails has made this easier for us. Update the routes.rb file to:

ActionController::Routing::Routes.draw do |map|  

  map.resources :albums

  #map.connect ':controller/:action/:id'
  #map.connect ':controller/:action/:id.:format'

end

Thanks to this one line, Rails will create a set of named routes – intelligent named routes. They are intelligent because they examine the request URL as well as the specified HTTP operation. Therefore the same URL can be routed to deferent controller actions.

As you may recall from part 4, when you use named routes Rails dynamically generates routing helper methods. These helper methods are also available on these new ‘intelligent’ named routes.

Experiment 5.2 Showing the Index Page

Let’s have a look at the table:

To show a list of albums we need to perform a GET with a URL of /albums. We can perform a get by simply typing the URL into the browser and pressing enter. If you try that you should end up with an error.

undefined method `destroy_album_path’ for #

This is good news as we did not get a route not found error. To get the index page up and running we need to replace the named route helper methods we introduced in part 4 with the helper methods created by ‘map.resources :albums’. The following table shows these ‘new’ helper methods.

This table shows methods ending with _url, the _path versions also exist. This was explained in part 4. By making use of these helper methods we can update the index.html.erb.

Thanks to our foresight in part 4, we only need to change the call to delete, from:

link_to ‘Destroy’, destroy_album_path(album.id), :confirm => ‘Are you sure?

To

link_to ‘Destroy’, album_path(album), :confirm => ‘Are you sure?’, :method => :delete

Just to be clear, the index.html.erb should look like this:

<h1>Listing albums</h1>
<table>
<tr>
<th>Title</th>
<th>Review</th>
</tr>
<% for album in @albums %>
<tr>
<td><%=h album.title %></td>
<td><%=h album.review %></td>
<td><%= link_to 'Show', album_path(album)  %></td>
<td><%= link_to 'Edit', edit_album_path(album) %></td>
<td><%= link_to 'Destroy', album_path(album), :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %></table>
<%= link_to 'New album', new_album_path %>

A URL of /albums should show the index page – test it if you like.

Alert!
Link_to obtains the URL by making use of another Rails method called ‘url_for’. The following quote is from the Rails documentation and it refers to the parameters being passed into url_for.

“If you instead of a hash pass a record (like an Active Record or Active Resource) as the options parameter, you‘ll trigger the named route for that record. The lookup will happen on the name of the class. So passing a Workshop object will attempt to use the workshop_path route”

This means that we can replace
link_to ‘Show’, album_path(album)
with
link_to ‘Show’, album

And
link_to ‘Destroy’, album_path(album), :confirm => ‘Are you sure?’, :method => :delete
with
link_to ‘Destroy’, album, :confirm => ‘Are you sure?’, :method => :delete

I am sure this bit of Rails magic has been the cause of much confusion.
This magic is also used in other methods e.g. redirect_to, form_for etc.

The index.html.erb can now look like this:

<h1>Listing albums</h1>
<table>
<tr>
<th>Title</th>
<th>Review</th>
</tr>
<% for album in @albums %>
<tr>
<td><%=h album.title %></td>
<td><%=h album.review %></td>
<td><%= link_to 'Show', album  %></td>
<td><%= link_to 'Edit', edit_album_path(album) %></td>
<td><%= link_to 'Destroy', album, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %></table>
<%= link_to 'New album', new_album_path %>
 

A URL of /albums should now render the index page.

Experiment 5.3 The RESTful Show

Thanks to the naming convention we used in part 4, we do not need to do anything to make show work. Show.html.erb remains like this:

  <b>Title:</b>
  <%=h @album.title %>

  <b>Review:</b>
  <%=h @album.review %>

<%= link_to 'Edit', edit_album_path(@album) %> |
<%= link_to 'Back', albums_path %>
 

Experiment 5.4 Edit RESTfully

To fix update we need to make use of the following methods in the edit view.

The form_for allows us to use more syntactic sugar.

We could use:
form_for (@album), :url => album_path(@album)

Or we could use:
form_for (@album)

This means the edit.html.erb should look like this:

<h1>Editing album</h1>
<%= error_messages_for :album %>

<% form_for (@album) do |f| %>

    <b>Title</b>
    <%= f.text_field :title %>

    <b>Review</b>
    <%= f.text_area :review %>

    <%= f.submit "Update" %>

<% end %>

<%= link_to 'Show', @album %> |
<%= link_to 'Back', albums_path %>

Experiment 5.5 Putting Delete to REST

This was fixed when we modified the index.html.erb.

The line was:

link_to ‘Destroy’, album, :confirm => ‘Are you sure?’, :method => :delete

Experiment 5.6 A RESTful Addition

In order to restore the ‘new’ functionality, make new.html.erb look like this:

<h1>New album</h1>
<%= error_messages_for :album %>

<% form_for (@album) do |f| %>

    <b>Title</b>
    <%= f.text_field :title %>

    <b>Review</b>
    <%= f.text_area :review %>

    <%= f.submit "Create" %>

<% end %>

<%= link_to 'Back', albums_path %>

Experiment 5.7 Updating the Controller to use the Syntactic Sugar

When using a resource the controller must implement these specific methods:
index, show, new, edit, create, update, destroy.
Our controller already meets this condition.

Although the music store is fully operational, we can make some minor modifications in the controller. This is just to leave the controller in the way Rails generated it in part 1. These changes are in the create and update actions e.g. redirect_to(@album)

The controller should look as follows:

class AlbumsController < ApplicationController
  # GET /albums
  # GET /albums.xml
  def index
    @albums = Album.find(:all)
    @cont = "The controller is:" + params[:controller]
    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render  ml => @albums }
    end
  end

  # GET /albums/1
  # GET /albums/1.xml
  def show
    @album = Album.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.xml  { render  ml => @album }
    end
  end

  # GET /albums/new
  # GET /albums/new.xml
  def new
    @album = Album.new

    respond_to do |format|
      format.html # new.html.erb
      format.xml  { render  ml => @album }
    end
  end

  # GET /albums/1/edit
  def edit
    @album = Album.find(params[:id])
  end

  # POST /albums
  # POST /albums.xml
  def create
     @album = Album.new(params[:album])  

     respond_to do |format|
       if @album.save
         flash[:notice] = 'Album was successfully created.'
         format.html { redirect_to(@album) }
         format.xml  { render  ml => @album, :status => :created, :location => @album }
       else
         format.html { render :action => "new" }
         format.xml  { render  ml => @album.errors, :status => :unprocessable_entity }
       end
     end
  end  

  # PUT /albums/1
  # PUT /albums/1.xml
  def update
     @album = Album.find(params[:id])  

     respond_to do |format|
       if @album.update_attributes(params[:album])
         flash[:notice] = 'Album was successfully updated.'
         format.html { redirect_to(@album) }
         format.xml  { head  k }
       else
         format.html { render :action => "edit" }
         format.xml  { render  ml => @album.errors, :status => :unprocessable_entity }
       end
     end
   end  

  # DELETE /albums/1
  # DELETE /albums/1.xml
  def destroy
    @album = Album.find(params[:id])
    @album.destroy

    respond_to do |format|
      format.html { redirect_to(albums_url) }
      format.xml  { head  k }
    end
  end
end

And that is that – our music store is exactly how it was when we generated it in part 1.

End of Part 5

To keep things ‘simple’ I have been skipping over certain aspects of routing. I will draft one more post in this series where I will mention some of these topics. Some of the readers have asked questions, I will still answer those questions but they won’t form part of this tutorial.

That concludes part 5. Hopefully you have a better understanding of what is going on under the hood.

Thank you, Daryn

Part 6

Part 5

The routes we have discussed so far are known as simple routes. I have been referring to them as custom routes, but ‘simple routes’ is the correct term. The default route we discussed in part 3 is also a simple route. The aim is to move onto RESTful routes, sometimes called resource routes. RESTful routes are built on top of named routes. Therefore we must first cover named routes, and that is what part 4 is all about.

Part 4

Introduction

Referring back to part 1, the routing system has two main functions:
Interpreting a request URL
Generating a request URL

We had a detailed look at route generation and interpretation in part 2, but let’s have another quick look at it. Let’s assume, for some insane reason, that we defined the following route in the music_store routes.rb file:

map.connect ‘apples/bananas/:id’, :controller => “albums”, :action => “show”

link_to would use this rule to generate a URL, this can be seen in the following line extracted from index.html.erb:

link_to ‘Show’, :controller => “albums”, :action => “show”, :id => album.id

This could generate a URL of: http://localhost:3000/apples/bananas/7
And when given this request, Rails would handle it correctly e.g. the show action will be called on the albums controller and the show view will be sent as the response to the browser.

Coming back to the real world, we are more likely to define the routing rule like this:
map.connect ‘albums/show/:id’, :controller => “albums”, :action => “show”

link_to (and friends) would then generate a URL like this:
http://localhost:3000/albums/show/7.

To show the index (the listing of the albums) we could define a rule like this:
map.connect ‘albums/index’, :controller => “albums”, :action => “index”

The matching link_to in edit.html.erb is:
link_to ‘Back’, :controller => “albums”, :action => “index”

Looking at the last example, there is some repetition. Both lines contain:
:controller => “albums”, :action => “index”

The link_to method needs this (controller, action) information to obtain the URL. If we had the URL stored as some global variable, or method, then we could simply pass that into link_to. link_to could use this ‘literal’ URL without needing to generate one.
This could look something like: link_to ‘Back’, albums_index_url
This is one of the main ideas behind named routes.

Named Routes

Named routes provide a way to ‘clean up’ code, specifically the code within link_to and other similar functions. When a named route is defined, new helper methods are dynamically generated. These helper methods provide a simplified way of obtaining the required request URL. The names of these helper methods are based on the name of the route. Let’s clarify this by coding.

Experiment 4.0 Preparation

At the end of part 3 the routes.rb had the default route in it:

ActionController::Routing::Routes.draw do |map|  

  map.connect ':controller/:action/:id'

end

It is common to accompany the default route with this:
map.connect ‘:controller/:action/:id.:format’
We can think of this as a default route which allows clients to request a different format for the response. :format was discussed in part 1, under the title of Experimenting 1 – View the generated routes.

To prepare for this session, we want to remove all the routes and completely break the site. Therefore you should make your routes.rb look like this:

ActionController::Routing::Routes.draw do |map|  

  # map.connect ':controller/:action/:id'
  # map.connect ':controller/:action/:id.:format'

end

Now the site is good for two things, serving up routing errors and learning about named routes…

Experiment 4.1 Adding a Named Route for the Albums Index

In part 2 we defined a route which invoked the index action on the albums controller. That route looked like this: map.connect ‘music’, :controller => “albums”, :action => “index”

To follow Rails convention, we should write it like this:
map.connect ‘albums’, :controller => “albums”, :action => “index”

Making it more readable we could write it like this:
map.connect ‘albums’,
:controller => “albums”,
:action => “index”

The pattern string is ‘albums’, therefore a URL of /albums would match.

In order to name this route, we need to decide what to name or call it. A top down approach is recommended for this. We want to show a list of albums, so it seems reasonable to call the route ‘albums’.

To name the route, we make a small change to our route definition. We change the route definition from:

map.connect ‘albums’,
:controller => “albums”,
:action => “index”

To:

map.albums ‘albums’,
:controller => “albums”,
:action => “index”

All we had to do is change map.connect to map.albums. Modify your routes.rb file to look like this:

  ActionController::Routing::Routes.draw do |map|  

    map.albums 'albums',
        :controller => "albums",
        :action => "index"

    # map.connect ':controller/:action/:id'
    # map.connect ':controller/:action/:id.:format'

  end

Once this file is saved, you will have created a named route. We are still missing most of the routes our site requires therefore we can’t run the site just yet. Let’s simplify the index page. Make the index.html.erb look like this:

<h1>Listing albums</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Review</th>
  </tr>

<% for album in @albums %>
  <tr>
    <td><%=h album.title %></td>
    <td><%=h album.review %></td>
  </tr>
<% end %>
</table>
<br />

Now you should be able to see the simplified index page. Next we will take a look at the methods that Rails generates when using named routes.

Experiment 4.2 Exploring the ‘Named Route’ Generated Methods

When a named route is defined, Rails will dynamically generate two methods, these are:
name_url and name_path (where name is the name of the route). name_url will return the fully qualified URL, name_path returns the relative path – it does not include the protocol and host.

In our case, we have a route named albums. When we run the site, rails will generate albums_url and albums_path. Let’s make the view display these values, change the index.html.erb to this:
I had to use different formatting to stop WordPress from getting up to its shenanigans…

<h1>Listing albums</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Review</th>
  </tr>

<% for album in @albums %>
  <tr>
    <td><%=h album.title %></td>
    <td><%=h album.review %></td>
  </tr>
<% end %>
</table>
<br />
albums_url: <%= albums_url %>
<br />
albums_path: <%= albums_path %>

Brows to http://localhost:3000/albums and you should see:
albums_url: http://localhost:3000/albums
albums_path: /albums

Now that we have seen the output of these methods, you can now remove those last three lines.

Academically speaking it is probably more correct to use name_url but name_path also works in most cases. The Rails way is to use name_path if you can. These methods are available in the views and controllers.

Experiment 4.3 Defining a Named Route for Show

Showing the index is fairly straight forward as it is basically a static URL. Now we look at defining a named route for show. Show needs to pass through the ID of the specific album. When defining a simple route, we could use:

map.connect ‘album/:id’,
:controller => “albums”,
:action => “show”

Once again, we can convert this into a named route by replacing connect with the name of the route. Let’s name the route ‘album’. Update the routes.rb to look as follows:

ActionController::Routing::Routes.draw do |map|  

  map.albums 'albums',
      :controller => "albums",
      :action => "index"

  map.album 'album/:id',
      :controller => "albums",
      :action => "show"

    # map.connect ':controller/:action/:id'
    # map.connect ':controller/:action/:id.:format'

end

Rails realises that it needs a value for :id, therefore the helper methods accept a parameter to be assigned to it. Therefore link_to can use album_url(3). This will hard code 3, but it illustrates the point.

In the code we are likely to use:
link_to ‘Show’, album_path(album.id)
Thanks to some syntactic sugar we can also use:
link_to ‘Show’, album_path(album)

Let’s get the ‘show’ functionality working again. Update index.erb.html to look like this:

<h1>Listing albums</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Review</th>
  </tr>

<% for album in @albums %>
  <tr>
    <td><%=h album.title %></td>
    <td><%=h album.review %></td>
	<td><%= link_to 'Show', album_path(album)  %></td>
  </tr>
<% end %>
</table>
<br />

And update show.erb.html to:

<p>
  <b>Title:</b>
  <%=h @album.title %>
</p>

<p>
  <b>Review:</b>
  <%=h @album.review %>
</p>

<%= link_to 'Back', albums_path %>

We have removed the link to ‘edit’, we will replace it later.

At this stage the site should be able:

• to show the list of albums in the index page
• show a single album

Experiment 4.4 Defining a Named Route for Edit

Now lets fix the edit functionality. Update routes.rb to look like this:

ActionController::Routing::Routes.draw do |map|  

  map.albums 'albums',
    :controller => "albums",
    :action => "index"

  map.album 'album/:id',
    :controller => "albums",
    :action => "show"

  map.edit_album 'albums/:id/edit',
    :controller => "albums",
    :action => "edit"

  map.update_album 'albums/:id/update',
    :controller => "albums",
    :action => "update"  

    # map.connect ':controller/:action/:id'
    # map.connect ':controller/:action/:id.:format'

end
 

You may have noticed that I am using slightly different pattern strings to what we have been using. The pattern strings (and URLs) that I am using now are fairly close to those used in REST. Therefore we are already getting familiar with the RESTful interface.

Update the index.erb.html to:

<h1>Listing albums</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Review</th>
  </tr>

<% for album in @albums %>
  <tr>
    <td><%=h album.title %></td>
    <td><%=h album.review %></td>
    <td><%= link_to 'Show', album_path(album)  %></td>
    <td><%= link_to 'Edit', edit_album_path(album) %></td>
  </tr>
<% end %>
</table>
<br />

 

Edit.erb.html should look like this:

<h1>Editing album</h1>

<%= error_messages_for :album %>

<% form_for (@album), :url => update_album_path(@album) do |f| %>
  <p>
    <b>Title</b><br />
    <%= f.text_field :title %>
  </p>

  <p>
    <b>Review</b><br />
    <%= f.text_area :review %>
  </p>

  <p>
    <%= f.submit "Update" %>
  </p>
<% end %>

<%= link_to 'Show', album_path(@album) %> |
<%= link_to 'Back', albums_path %>

Add the edit link back to show.erb.html

  <p>
  <b>Title:</b>
  <%=h @album.title %>
</p>

<p>
  <b>Review:</b>
  <%=h @album.review %>
</p>

<%= link_to 'Edit', edit_album_path(@album) %> |
<%= link_to 'Back', albums_path %>

At this stage the site should be able:

• to show the list of albums in the index page
• show a single album
• Edit an existing album

Experiment 4.5 Defining a Named Route for Destroy

Update the routes.rb to this:

ActionController::Routing::Routes.draw do |map|  

  map.albums 'albums',
    :controller => "albums",
    :action => "index"

  map.album 'album/:id',
    :controller => "albums",
    :action => "show"

  map.edit_album 'albums/:id/edit',
    :controller => "albums",
    :action => "edit"

  map.update_album 'albums/:id/update',
    :controller => "albums",
    :action => "update"  

  map.destroy_album 'albums/:id/destroy',
    :controller => "albums",
    :action => "destroy"     

    # map.connect ':controller/:action/:id'
    # map.connect ':controller/:action/:id.:format'

end

The index.erb.html should look like this:

<h1>Listing albums</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Review</th>
  </tr>

<% for album in @albums %>
  <tr>
    <td><%=h album.title %></td>
    <td><%=h album.review %></td>
	<td><%= link_to 'Show', album_path(album)  %></td>
	<td><%= link_to 'Edit', edit_album_path(album) %></td>
	<td><%= link_to 'Destroy', destroy_album_path(album.id), :confirm => 'Are you sure?' %></td>
  </tr>
<% end %>
</table>
<br />

I am sure that you are getting a feel for named routes now…

At this stage the site should be able:

• to show the list of albums in the index page
• show a single album
• Edit an existing album
• Delete an album

Experiment 4.6 Defining a Named Route for New

Change the routes.rb file to this:

ActionController::Routing::Routes.draw do |map|  

  map.albums 'albums',
    :controller => "albums",
    :action => "index"

  map.album 'album/:id',
    :controller => "albums",
    :action => "show"

  map.edit_album 'albums/:id/edit',
    :controller => "albums",
    :action => "edit"

  map.update_album 'albums/:id/update',
    :controller => "albums",
    :action => "update"  

  map.destroy_album 'albums/:id/destroy',
    :controller => "albums",
    :action => "destroy"     

  map.new_album 'albums/new',
    :controller => "albums",
    :action => "new"  

  map.create_album 'albums/create',
    :controller => "albums",
    :action => "create"  

    # map.connect ':controller/:action/:id'
    # map.connect ':controller/:action/:id.:format'

end

The index.erb.html should now be:

<h1>Listing albums</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Review</th>
  </tr>

<% for album in @albums %>
  <tr>
    <td><%=h album.title %></td>
    <td><%=h album.review %></td>
	<td><%= link_to 'Show', album_path(album)  %></td>
	<td><%= link_to 'Edit', edit_album_path(album) %></td>
	<td><%= link_to 'Destroy', destroy_album_path(album.id), :confirm => 'Are you sure?' %></td>
  </tr>
<% end %>
</table>
<br /><%= link_to 'New album', new_album_path %>

To stop WordPress from deleting my code, I put link_to ‘New album’  on the same line as the br tag. They are on separate lines in my actual code.

With new.erb.html looking like this:

<h1>New album</h1>

<%= error_messages_for :album %>

<% form_for :album, @album, :url => create_album_path do |f| %>
  <p>
    <b>Title</b><br />
    <%= f.text_field :title %>
  </p>

  <p>
    <b>Review</b><br />
    <%= f.text_area :review %>
  </p>

  <p>
    <%= f.submit "Create" %>
  </p>
<% end %>

<%= link_to 'Back', albums_path %>

At this stage the site should be able:

• to show the list of albums in the index page
• show a single album
• Edit an existing album
• Add a new album

Are we done? What about the controller?

Experiment 4.7 Using Named Route Helper Methods in the Controller

Open the controller and look at the destroy action, you will notice this line:

format.html { redirect_to(:controller => “albums”, :action => “index”) }

This shows you that we can still generate routes as if we were using the simple routes. We have defined named routes, we can use the helper methods in the controller, so we might as well.

Make the controller look like this:

class AlbumsController < ApplicationController
  # GET /albums
  # GET /albums.xml
  def index
    @albums = Album.find(:all)
    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render  ml => @albums }
    end
  end

  # GET /albums/1
  # GET /albums/1.xml
  def show
    @album = Album.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.xml  { render  ml => @album }
    end
  end

  # GET /albums/new
  # GET /albums/new.xml
  def new
    @album = Album.new

    respond_to do |format|
      format.html # new.html.erb
      format.xml  { render  ml => @album }
    end
  end

  # GET /albums/1/edit
  def edit
    @album = Album.find(params[:id])
  end

  # POST /albums
  # POST /albums.xml
  def create
     @album = Album.new(params[:album])  

     respond_to do |format|
       if @album.save
         flash[:notice] = 'Album was successfully created.'
         format.html { redirect_to(album_path(@album)) }
         format.xml  { render  ml => @album, :status => :created, :location => @album }
       else
         format.html { render :action => "new" }
         format.xml  { render  ml => @album.errors, :status => :unprocessable_entity }
       end
     end
  end  

  # PUT /albums/1
  # PUT /albums/1.xml
  def update
     @album = Album.find(params[:id])  

     respond_to do |format|
       if @album.update_attributes(params[:album])
         flash[:notice] = 'Album was successfully updated.'
         format.html { redirect_to(album_path(@album)) }
         format.xml  { head  k }
       else
         format.html { render :action => "edit" }
         format.xml  { render  ml => @album.errors, :status => :unprocessable_entity }
       end
     end
   end  

  # DELETE /albums/1
  # DELETE /albums/1.xml
  def destroy
    @album = Album.find(params[:id])
    @album.destroy

    respond_to do |format|
      format.html { redirect_to(albums_path) }
      format.xml  { head  k }
    end
  end
end

Sure we have a larger routes.rb file, but I am sure you will agree that  redirect_to(albums_path)

is much better than redirect_to(:controller => “albums”, :action => “index”)

The End of Part 4

I hope this has helped you to get familiar with named routes. There is a lot more to them, and there is also a lot more syntactic sugar. Once I have completed the section on RESTful routing, I might do a summary post. This would be a recap and it will show some tips and tricks that I skipped over in these posts. I am skipping certain topics as I would like to get onto RESTful routing as soon as possible.

Speaking of RESTful routing, the way we have named the routes is very close to the RESTful way. You will see this in the next post.

It is very easy to make mistakes when writing a tutorial like this. Especially with the gremlins inside of the WordPress formatting engine. If you are one of the first to complete this session successfully then please inform me. More importantly, if you find a problem please let me know.

Thank you, Daryn

Part 5