script/plugin install git://www.jandaweb.com/assert_valid_xhtml
Then add config.include ValidateXhtml to your spec/spec_helper.rb
Now you're ready to do
it "should be valid" do
render "/some/template"
response.should be_valid_xhtml
end
The matcher will not validate your view with its full layout, as I haven't worked out how to get views to render with a layout from a view test. Instead, it wraps a valid XHTML header / footer around the rendered template.
Let me know if you can do this better!
Rails 2.1 and git only. You still need to install the libxml-ruby gem, and you need git installed to install the plugin. Install plugin with:
script/plugin install git://www.jandaweb.com/assert_valid_xhtmlThe responsible_markup plugin from codahale is fine and dandy if you want all the features and you're always connected to the net. If, however, like me, you're moving around a bit and sometimes get a dodgy connection, or simply want to speed up your functional tests' XHTML validation, give this a spin.
It's an assertion that can be stuck into your test_helper.rb or made into a plugin as you see fit. I didn't think it was worth making a special plugin just yet, as it's very limited in scope.
It assumes you're doing XHTML 1.0 validation.
Install the libxml gem:
sudo gem install libxml-ruby
Download the XHTML 1.0 DTDs to a special directory:
cd YOUR_RAILS_PROJECT
mkdir doc/dtd
cd doc/dtd
wget http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
wget http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent
wget http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent
wget http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.entNow you're ready to paste some code. Open up your test/test_helper.rb and stick the following require lines somewhere at the top, after "require 'test_help'":
require 'xml/libxml'
require 'md5'We'll be doing some md5 hashing to (almost) guarantee unique versions of markup.
Here's the assertion!
def assert_valid_xhtml
checksum = MD5.new(@response.body)
path = "/tmp/assert_valid_xhtml_#{checksum}"
return true if File.exists?("#{path}-valid")
dtd = XML::Dtd.new("-//W3C//DTD XHTML 1.0 Strict//EN",
RAILS_ROOT + '/doc/dtd/xhtml1-strict.dtd')
unless File.exists?(path)
File.open(path, 'w') { |f| f.puts @response.body }
end
doc = XML::Document.file(path)
if doc.validate(dtd)
FileUtils.mv(path, "#{path}-valid")
else
assert false
end
endNow you can stick "assert_valid_xhtml" after any request to make sure it's valid. Okay, so the results don't come back too pretty and they go to STDERR instead of the failure notice, but this was knocked together quickly.
If you want to see what the code is doing try a "watch ls /tmp" while rake is running. You'll see the files being marked off as valid as it works.
Since the Rails core team switched to git a lot of rails developers have followed suit. Not wishing to be left out, I have been moving some projects to git recently, although somewhat unusually I have been migrating from darcs. git seems pretty good now that I understand the basics, but the documentation for getting started did leave me a little confused. To compensate, here is my 10 minute crash course in getting started with git.
This guide assumes that you are working in a small team, have a central server with git installed and are familiar with ssh.
In the git world, every developer has their own full copy of the repository. This is where their changes get committed to. However, with each developer having their own repository and these repositories being in different states it is difficult to say what the authoritative state of a project is. This is easily solved by setting up another central copy of the repository which all developers have access to and to which changes are pushed when they are ready to be shared with the world.
I set this up in the quickest/easiest way I could be creating a new user called 'git' on our development server and adding each developer to the authorized_keys file. I then created a directory called repos under the git user's home directory to store all of the git repositories.
I decided to move an existing internal (for now) project called panda from darcs into git. You can use tailor to convert between the two different SCMs, but I was lazy and just ditched the darcs history and started the git repository from the current working version.
On my laptop (where I write most of my code), I got a fresh copy of the latest panda code and removed the _darcs directory. (This is similar to doing an svn export.) Next, I turned it into a git repository with git init. This creates the git repository but does not add any of the existing files to it. You can see this by running git status. You'll see a whole load of files that haven't been added to the repository yet.
Before we add all the files, it's worth taking the time to tell git to rails' temporary or generated files. (This is the git equivalent of _darcs/prefs/boring or svn propset svn:ignore.) Edit the file .git/info/exclude and add the patterns of the files you want to ignore. I added:
log/*.log
db/schema.rb
db/*.sqlite3
nbproject
(That last one is to ignore NetBeans' files.) You might want to add the various tmp directories too. Now you can add the rails project files to the git repository with git add .
One problem remains. The extremely observant amongst you might have noticed that the log and lib (and a few more) directories don't show up in the output of git status. This is because git (stupidly) doesn't track empty directories. To force git to include them, create an empty file in these directories and run git add . again. (You might want to add -v to git add . to see what it's adding.) I did this with:
~/git/panda$ touch log/.gitinclude
~/git/panda$ git add . -v
add 'log/.gitinclude'
You can now commit your changes (git commit) and we're ready to push them centrally. To prepare the ground, create a repository on the central server to push the content into. On the central server, as the git user, I created /home/git/repos/panda then changed to this directory and ran git init. Back on my laptop, I named this remote repository to save me having to remember and type the full location each time. I did this with git remote add origin git@name.of.server:repos/panda. Now I'm all ready to push the changes, which I can do with git push origin master.
Branches in git are pretty much the same as branches in any other SCM (except, of course, darcs which is too clever to need branches). However, if you come from an SVN background it is important to understand that the branch/edit/merge cycle is not only best practice, it is thankfully easy to do.
Having each developer always work in a branch is a great way of ensuring that
master stays clean and represents the latest stable version of the projectBranches are good. Start using them from the outset and life becomes easy later.
The typical branch/edit/merge cycle in git is easy to do, although it does suffer from unfortunate naming. The checkout command is used to switch between branches, and is the most common way of creating a new branch. The flow for carrying out some work is:
$ git checkout -b <name of branch> (a)
<make some changes>
$ git status (b)
$ git add . (c)
$ git commit (d)
git add <path> rather than git add .Steps c and d can be combined into git commit -a if you are confident that you know what has changed.
Branches are not created for every change you make, but rather for groups of changes. I tend to create a new branch for every user story I work on, and commit after each acceptance criteria is met, or more frequently if an acceptance criteria requires many steps to satisfy.
Once you have finished (and committed) some work that you want to share with other developers then the git process is to merge the changes back into the master branch and push them to the central server so that other people can pick them up. The master branch was created automatically when you ran git init and this is the branch which should hold the latest stable version of the project.
Merging is easy under git. First, change to the master branch using git checkout, and then merge the changes in using ... git merge. The steps are:
$ git checkout master
$ git merge <name of branch>
Assuming there are no conflicts, you can then push this newly merged master back to the central server with:
$ git push origin master
...and everyone can pick up your changes.
I have only been dabbling with git for about one month now, and only using it in anger for the past week. Inevitably my current 'best practices' will change as I get to know it better. There may be better ways of doing some of the above steps, and there is a lot that I didn't talk about. However, hopefully this will be enough to get you start with your own shared git development.
Setting the class attribute in the <body> element of a page can be really handy for CSS and JavaScript hooks. For example, if I wanted all pages with the class "checkout" to be laid out in a particular way, I could simply add the class to all the pages that were in the checkout phase, then add some CSS rules for ".checkout".
Rails' content_for method is useful for including sections of markup that don't fit in the main content of a page. But when it comes to setting classes for the body tag, content_for doesn't really cut the mustard.
Here was my attempt at using content_for to set a template's body class:
<% content_for :body_attributes, 'class="checkout"' %>Then, in my layout:
<body <%= yield :body_attributes %>>
This worked well until I wanted to add a class that indicated the current controller. Since I'd already explicitly set "class=" in each template, I couldn't easily modify the attribute to add further classes.
So I wrote a helper to do this better. Here it is!
def body_classes
@body_classes ||= [controller.controller_name]
endAs you can probably guess, the @body_classes instance variable defaults to an array with a single item: the name of the current controller. Handy for controller-wide CSS changes.
Here's how to call it from your layout.
<body class="<%= body_classes.join(' ') %>">So now when you want to add an extra class to the default controller name, simply do the following from your template.
<% body_classes << 'checkout' %>
Since class names are separated by spaces, array manipulation is a lot more suitable for this task than content_for.
If you've ever been maddened by Markdown or troubled by Textile then Johndown might be what you're after. We'll soon be releasing this new text to XHTML language that we use on our own internal tools. As the name implies, it was originally written by John and is based on Markdown. It's written entirely in Ruby and will have full open source code, with an accompanying Rails plugin.
The unintuitive bits of Markdown that Johndown addresses: