I believe that the CSS class is generally the best mechanism for expressing the semantic meaning of a particular piece of html (combined with DOM location and html tags). For example if somehow in viewing an order we want to reorder the order then I would first produce

.order
  .reorder
    # re-order goes here

This clearly establishes the semantic meaning - that I can reorder an order. Now the actual UI could be a number of things

• Instructions: Reorder by phoning 0800 555 5555 and quoting order#
• a button [reorder]
• a link click <here> to reorder

Now as far as my business requirement and feature is concerned I don't care about these implementation details, and these details are certainly volatile. However the semantic layout is fixed. Here I see a representation of an order and can reorder the order.

I can now refine this feature to state that I should be able to tell the order to reorder. When I do this I should see some response in the UI which indicates whether my command has been successful.

When I reorder
Then I should see ...

In web applications you can do this in two ways

• follow a link
• submit a form (by pressing a button)

Again my feature does not care how I reorder unfortunately with webrat I now have to choose - I can either 'click' or 'press'.

.order
  .reorder
    %a{:href => order_path(:id => order.id)}= h(order.name)

above I am 'clicking' a link, whilst below I am pressing a button

.order
  .reorder
     -form_for @order do |f|
       ... 
       f.submit "reorder"

Now as far as my feature is concerned I don't give a damn how the re-ordering is done I just want to reorder. However I have to change my scenario (yes I know I can hide this change to a degree by re-using steps and having fancy step definition).

Scenario: Reorder
Given there is an order
When I view orders 
And I click reorder
Then ...

     OR 

Scenario: Reorder
Given there is an order
When I view orders 
And I press reorder
Then ...

Webrat compounds this frustration by making it really hard to press or click. Currently it will click only using text, id or an href, and its even more restrictive when it comes to pressing. So my first improvement was to extend click link to also be able to use classes. Now at least I can do

click link reorder

Although I have to change my implementation code

.order
    %a{:clases => reorder, :href => order_path(:id => order.id)}= h(order.name)

There are several issues to consider here

• obtrusive javascript
• supporting browsers where javascript is disabled
• restful design and current browser limitations

restful design and current browser limitations

Restful design stipulates that to delete a resource you should call its url using the delete method on it. So with an item foo you would use the same url to delete and show foo

• www.example.com/foo with GET to show
• www.example.com/foo with DELETE to delete

However current browsers only support the GET and POST verbs, so we have to get around this. What Rails does is overload POST passing the method (PUSH, DELETE, HEAD?). This means a form has to be created for each delete link. Rails uses javascript to create this form on the fly (and the very convenient confirmation dialog. This approach allows us to use the correct REST url to delete things.

supporting browsers where javascript is disabled

When javascript is disabled it becomes harder to delete things. If we try and use a link to delete we will instead send a GET and show foo. Rails does this because without javascript we cannot rely on the additional safety of a browser side confirmation. So Rails says we should not use a link for deleting but instead use a button (use method button_to). However buttons are clunky so people expect to be able to work around this limitation. There are a couple of solutions to this problem

1. use a button rather than a link, and lose the ability to confirm that action
2. insist on javascript so we can use pretty links to delete and have our confirm
3. create another url for deleting things which will show a confirmation form when javascript is disabled and then post the DELETE (this breaks the RESTFUL design a little)
4. wait for browser to support DELETE

obtrusive javascript

Another problem highlighted by this issue is the yukky javascript that the Rails helpers insert directly into our HTML. If we have a table of items that can be deleted we end up with 5 lines of convoluted javascript for each item. So we have our beautiful semantic html polluted by reams of 'obtrusive javascript'. I'll talk about this issue further in a separate post

references

Railscast 77