Section :: Blog

Visual Ruby On Rails Drag and Drop Designer

by Huw Collingbourne

Another short demo of the Visual Rails Workbench

Friday 1 February 2008.

The Visual Rails Workbench - drag and drop design for Rails applications

To give you some idea of how you will be able to create a visual interface for a web application using our forthcoming Visual Rails Workbench, here is a short walkthrough of a simple design being ‘round-tripped’ between ERb templates and a fully-formed HTML page...

Here I am starting out with a view template, new.html.erb. This is ‘Rails format’ code - a mixture of HTML and embedded Ruby...

I click a button at the bottom of the Visual Rails Workbench to switch to the page designer. Notice that the view template (the Post entry form) for this specific web page has automatically been combined with the associated layout template (containing the logo and the blog name) which defines a consistent look for all the pages on the web site...

Now I just click and drag the controls on the page in order to move or resize them. I can also edit the text ‘in place’ and make adjustments to colours and other properties...

I notice that I have forgotten to add a DateTimePicker. No problem, the Visual Rails Workbench has a number of ready-to-use components in the Toolbox. I select the DateTimePicker....

...and drop it onto the form. This automatically adds a set of combo boxes populated with values to allow the user to select years, months, days and times.

I can verify that the HTML contains all the data I expect for the DateTimePicker by switching to ‘split’ editing mode so that I can view the visual design and the HTML code simultaneously.

Although all this has been done in the HTML designer, I can instantly switch back to the ERb (‘Rails format’) editor and here I can see that the DateTimePicker has been translated into embedded Ruby.

When I want to continue with the visual design I can switch right back to the HTML designer and carry on. My changes will be automatically translated back into Rails (ERb) format later on...

This has been a very simple demo of some of the capabilities of the Visual Rails Workbench. The Workbench will also give you the ability to export your page designs (in HTML) format to other applications such as Dreamweaver and subsequently import them and translate them back to ERb (see: Visual Rails Workbench - The Import/Export Business. The Visual Rails Workbench will form a part of the next version (1.2) of Ruby In Steel Developer - a free upgrade to registered users.

Add to del.icio.us

Comment on this article

Forum

Visual Ruby On Rails Drag and Drop Designer
7 February 2008, by John Honovich

This is pretty amazing.

For the example of a form, what if your form was populating multiple objects?

Sometimes, you need to use a check_box_tag field inside of a form_for field, etc.

You also often have to check that the params hash submitted matches up with the model fields or finders you want to populate.

How does that work?

This would be a fantastic productivity boost if it could handle these type of scenarios.

thanks,

John

Reply to this message
- Visual Ruby On Rails Drag and Drop Designer
  7 February 2008, by Huw Collingbourne
  
  We don’t guarantee thst it will handle every possible scenario. However, we have tried to handle all common cases and we will work with users to deal with anything we may have missed out ;-) Currently we can drag and drop forms and populate them with standalone or data-bound (model syntax) ’controls’ such as buttons, text areas, date-time pickers and so forth. There are built in tools to save ’versions’ of your design as you go along so you can always backtrack to one of multiple named earlier designs. Rails being as it is, I am sure some people will be using third-party add-ins that create controls which we don’t know about - maybe constructed from multiple separate elements that may confuse the designer (for example, a data-time picker is, in fact, a collection of speciallly initialzed combos rather than a single ’control’ - this is one we handle but there may be others we don’t know about). If there are things the designer can’t automtically handle then the user will be able to mark areas to be passed ’verbatim’ (without translation). At any rate, we’ll be putting this out to beta testers shortly and we’ll try to make sure that we deal correctly at least with all the commonly used design elements.
  
  best wishes
  
  Huw
  
  Reply to this message