Visual Rails - laying the foundations...
I’ve been working busily away for the last few months, hiding under my rock, and constructing the next iteration of Ruby In Steel: the Visual Rails Workbench. The terms ‘visual’ and ‘Rails’ don’t normally go well together – a bit like oil and water. A Rails ‘view’ is essentially a set of highly non-visual ‘directives’ that spit out HTML when needed. Normally, what I (and most people I know) mean by ‘visual’ is drag-and-drop WYSIWYG – like Visual Basic or C# in Visual Studio.
Unfortunately, you can’t really do that with Rails views – they are just too non-visual. From my experience of Rails, what you get out at the end is the result of a trial-and-error process, mixing in layouts, partials, the view and a whole set of directives. At design-time, it’s very difficult to see what’s going on.
What we are doing in RiS 1.2 will (hopefully) make the whole experience of designing web pages a bit less like dental surgery without anaesthetic. Over the next few weeks, I’ll be detailing what we’ve done and how it will make the production of first class web pages easier.
I’ll start with the first problem that I fell over when I started this work. In a Rails view, you’ll often see directives like this:
<% form_tag :action => 'update' do %>
<% end %>
This is actually a genuine piece of syntactically correct Ruby code. After the initial
<% comes form_tag, which is a method, and :action => ‘update’, which is its single argument. The do is the start of a block and it matches up with the end. What Rails does is invoke this method and insert the resulting HTML in a page for rendering by a browser. Very neat!
What isn’t so neat is the way that the do binds to the form_tag and not to the hash. This is not easy to deal with in an ANTLR LL(2) parser because the do is an unknown number of symbols ahead. It would be a lot easier and clearer if brackets were used to force the binding - but that’s Rails for you. In the RiS 1.1 parser, I’d, um, ‘forgotten’ about this and the do binds incorrectly to the hash. Now that isn’t a real problem for IntelliSense because it doesn’t have any effect for hover, etc.
But it does have an effect if you need to parse the method, its arguments and the block in order to emit HTML code. I have fixed the problem in 1.2 and the form_tag block is correctly handled by the Visual Rails Workbench.
More of that next week...
|This article describes a feature that is currently in development and will be released as part of Ruby In Steel Developer 1.2|
It sounds like you’re using ANTLR v2.* to parse your code. Have you considered looking into ANTLR v3.0 - which uses a LL(*) (arbitrary lookahead) parser? I’m assuming you’re probably aware of this, so I’d be curious as to why you didn’t go with this?
Yes, that’s correct - it’s ANTLR 2.6. The reason I’m using it is that v3 wasn’t out when I started this 18 months ago now.
The reason I haven’t switched yet is that v3 is very new and like any other new product will have bugs. One of the really, really nice things about ANTLR 2 is that I’ve now written about six parsers in it and I’ve not found a single bug. The main Ruby one is by far the most complex, and while some aspects of ANTLR 2 are a bit clunky and difficult to work with, it does a superb job.
The main thing that’s missing in the current Ruby parser is support for arbitrary expressions in mutiple left hand sides of an assignment - sort of like the method ... do thing, but a lot nastier for LL(2). It can be done but it takes forever to parse.
ANTLR 3 is scheduled for later on this year when its settled in a bit. I have to say I’m really looking forward to using it. I’m a big fan of Terrence Parr and ANTLR.