May 2007 Archives

A super high level workflow/application mark-up language

About a month or two ago, I was gabbling about a mark-up language for web apps with the under-achiever goal of covering the bottom 75%-ile in terms of complexity of CMS & workflow web app functionality. This mark-up language would describe the functionality and workflow of an application without seriously considering (for now) any presentation issues. So, it’s a functional but ugly web application mark-up language (FBUWAML). There could be many uses, but the most immediate one that comes to mind for me is super fast prototyping.

The goals of this project are

1. To be able to generate web apps in an XML/HTML-like language that truly stays at the application level / requirements gathering level, and
2. To target web designers rather than programmers—kinda like the way HTML does.

An implementation of this XML standard (ie. a program or script) would do the database configuration & schema generation/destruction/ modification automatically, so that users wouldn’t have to mess with MySQL, PhpMyAdmin or anything like that at all.

Posted by David Beckwith on May 19, 2007

How to organize your controllers in RoR

Ruby on Rails (RoR) is an MVC framework. Let’s think about what “C” means. “C” stands for controllers. The controller layer is where you collect and organize all of your business rules. That is, business rules and decision making ability generally DOES NOT leak into your M or V level, but instead these rules are grouped into named controllers.

For the purpose of this discussion let’s say we were trying to build the following application:

• 5 module complex work flow system. (e.g., automobile design aid: module 1 – spaceframe, module 2 – drivetrain, module 3 – aerodynamics, module 4 – environmentals, module 5 – controls)
• Each of these modules are fairly complex and should themselves be implemented as n-step wizards
• The modules can either be used in sequence to complete an end-to-end design project (XYZ Concept Car), or they can be used independently to assist in the design of a single subsystem or multiple independent subsystems. i.e., a project can encompass one or more modules
• Some modules will produce data that other modules can use to complete their particular function (for example: controls module needs to know about drive train and environmentals)

What’s the best way to organize the controllers in such an application?

Posted by David Beckwith on May 19, 2007