Visual Rails Workbench - The Import/Export Business
I mentioned previously that the Visual Rails Workbench - which forms part of our forthcoming upgrade (1.2.) to Ruby In Steel Developer - provides a drag and drop visual workspace in which to edit Rails web pages. But maybe you (or your designer) would prefer to use some other web design tool for this job...
Well, if you are using the Visual Rails Workbench, you can do that too. Using Ruby In Steel, you can create basic ERb (or RHTML) templates in the usual way - as collections of HTML ‘page fragments’ (Layouts, Views and Partials) containing embedded Ruby code. When it comes time to give a page a pixel-perfect makeover, the Visual Rails Workbench can assemble and translate all the ERb/RHTML templates into a fully-formed HTML page. Export that page. Design it in your favourite HTML editor, import the end result and let the Workbench re-translate it into the various ERb Layout, View and Partial templates required by Rails.
|It’s worth pointing out that you are not obliged to export your designs. You can do full-page drag and drop visual design right inside Ruby In Steel. Importing and exporting to and from another editor/IDE is entirely optional. However, as many professional web designers will want to use their favourite IDE - which may not be Visual Studio! - we believe this is an important capability.|
From Ruby In Steel To Dreamweaver - and Back Again...
Here is a quick walkthrough showing how we exported web pages for a Ruby On Rails Blog application from the Visual Rails Workbench to Adobe’s Dreamweaver. Here they were further designed before being important back into Ruby In Steel...
Create a Rails application in Ruby In Steel
The Visual Rails Workbench lets you code individual files or create a full page out of its component ERb templates.
Create an HTML page from ERb templates
This is done automatically by the Visual Rails Workbench. You can see which parts of an HTML page correspond to the ERb templates (Layout/View/Partials) - shown by coloured overlays in the Code Editor and branches in the Document Outliner
Use the Visual Designer
Drag, drop, move and resize controls, set properties, add images and text and create CSS styles - right inside Ruby In Steel.
Export the Page Design
But maybe you, or a colleague, prefer to do the page design in another IDE such as Adobe’s Dreamweaver. No problem - just export the page design as HTML.
Open the page in Dreamweaver
In fact, open it in any web editor of your choice. Edit styles, change fonts, add graphics and so on. The exported page is HTML so the editor doesn’t need to ‘understand’ Rails.
Design and Save The Page
The page - still in Dreamweaver - has here been given an extensive makeover. Some elements apply to specific views; others, such as the background, define the Layout of all the pages in the Rails site.
Import the redesigned page
Back in the Visual Rails Workbench, I select Import to load up the page which I have just designed in Dreamweaver.
Use the page in Ruby In Steel
I can carry on designing the page in Ruby In Steel if I wish. Once I am happy with the results, selecting Commit will cause the page to be deconstructed, translated from HTML to ERb and saved into its various component template files.
Run the application
The proof of the pudding is in the running - here I am testing the Rails application inside a web browser - and, sure enough, the design work that was done both in Ruby In Steel and in Dreamweaver appears in the running application...
The Visual Rails Workbench will form a part of the next version (1.2) of Ruby In Steel Developer. This will be a free upgrade to registered users.
It looks very promising. I just wonder how do you remember page structure during export to be imported later. Into HTML comments ? I don’t see any robust solution for this problem.
The structure is preserved using named DIVs which are identified using a namespace. We can construct HTML from ERb/RHTML in this way - we can also construct ERb/RHTML from HTML (so you could actually start with an HTML page if you wish and create ERb tempaltes from this). We take care of inserting the appropriate DIVs automatically when moving from ERb to HTML. It is, of course, the responsibility of the user to ensure that the DIVs we insert into the HTML are not removed prior to deconstructing the code back to ERb. We had thought of using comments (as Dreamweaver does to mark template areas) but we eventually decided that DIVs provided a better solution as they form part of the actual structure of a page and can be recognized, marked and manipulated as ’real’ HTML by Visual Studio, Dreamweaver and other editors.
Wow great work here guys, this is something very slick :)