Your current filters are…
Here's an example of a typical development workflow: designers do wireframes, mockups, page layout, visual design, typography, CSS and markup. And hand it over to developers to wire it up with ruby code. It is quite unrealistic to assume that view layer will have zero ruby code (you will, at least, need print statements!). Now, once the markup is wired up with ruby code, maintenance becomes a problem for designers. A designer cannot go back and change the markup without a developer. Also, to multiply the problem, there are partials. So, designer can never look at the markup as ONE single HTML page and make design improvements. And if you'd look closely, the 'hand over markup' part suggests that this entire workflow is NOT agile!
Enter hquery: Invented by (Chew) Choon Keat from Singapore (github.com/choonkeat), hquery is an unobtrusive server script implementation for Ruby on Rails - github.com/choonkeat/hquery. It is a rails plugin which lets you manipulate HTML markup using selectors etc, almost like jquery, except that it is on server. It was Choon Keat himself who introduced and demonstrated this powerful plugin to us while he was working with us at SlideShare. Since then, we've adopted this markup/code separation technique for all important pages at SlideShare. And it makes our developers and designers much happier. We find them playing Mortal Kombat on PS3 more than in their real lives now.
The idea is that you have 2 files - .hquery and .hquery.html for every webpage you need. .hquery.html is ONE file with entire HTML markup needed to render the page. And, .hquery has code which uses hquery plugin to replace markup in the .hquery.html file with ruby code and turn it into a .erb file. .hquery file is used to compile .hquery.html into .erb files. Obviously, replacing markup with ruby code and then rendering it on the fly will get expensive soon. So, this transformation of plain HTML files to .erb files can happen once during the application deploy step.
The end products (.hquery file and .hquery.html) are more maintainable, especially as logic piles on. There is a clear separation of the designed web page and it's structure (.hquery.html) and the server data that's weaved in (.hquery). The connecting factor is CSS class names that act as hooks to connect the two separate layers.
During the talk, we'd like to show demos of how we use hquery and talk about pros/cons and more advanced stuff like code reuse etc.
20th–21st March 2010