Hi Dondi & Pimpmaster,
I'm not an expert, and I don't know what engines are, but I am thinking about how to organize my controllers and came across this discussion, so I figured I'd put in my two cents.
Rails 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.
So, each controller represents a group of business rules or a decision making process. Using this line of associative reasoning, your sample workflow application, I suggest, should be organized like this:
And each step in your workflow should be a different action. Here, all of the business rules associated with your spaceframe construction workflow are grouped in the spaceframe controller. And all of the business rules relating to the drivetrain construction workflow are put into the drivetrain controller. Now what about actions?
So let's say your spaceframe wizard/workflow has three steps. But what are steps? Steps are a further "breakdown" of business rules and decisions. The business rules & decision for each step would be in an action. Let's say you were hosting your application at yourapp.com. And you had an action called "step1," "step2," and "step3."
You could do the same thing for your "drivetrain" workflow:
So basically the mapping for your process is:
WORKFLOW -> CONTROLLER
WORKFLOW STEP -> ACTION
No rocket science here.....I'm just reasoning from first principles: MV*C*.
Just as CONTROLLERS are about processes, MODELS are about things whose features you what to track. That's where you would track features of your drive train and space frame.
THING WITH FEATURES YOU WANT TO TRACK ==> TABLE IN DATABASE ==(WRAPPED BY)==> MODEL
I'm just guessing but maybe there is something called a "space frame" with actually features that you want to track .... like height, width, weight, and price. Then you should have a table called SPACEFRAMES and a model to wrap that up called /model/spaceframes.rb.
etc.... The model is where you model your world with THINGS THAT YOU WANT TO TRACK IN THE DATABASE. That model may or may not correspond in a 1-to-1 fashion with your workflow. There may be a complicated combination of features with different values of your model objects that need to interact to be able to make a decision in your action/controller/workflow/business rule. (E.g. If Controls.temperature * Drivetrain.mass > CRITICAL_HEAT redirect_to :action => 'emergency_shutdown') That's why we separate those three layers.
If you wanted to actually edit/destroy/view the values of a spaceframe, then you would do that in the spaceframe controller ((/controllers/spaceframe_controller.rb)) as distinct from the spaceframe workflow controller (/controllers/spaceframe_workflow_controller.rb).
Your URLs for managing your things in your world woud look like this:
Does that answer your architecture question? I think it's a pretty innocent and straightforward way to organize the app as you described it, but it should suffice for the first iteration. As you guys were saying before, if you need to get fancy and abstract things out and refactor, then you can do that in future iterations as you see necessary.
As an afterthought, I guess you can think of controllers and actions as two levels of "directories" to organize your business rules.....hmmm.... what if you need three levels?
Last edited by dbit_solutions (2007-05-14 06:10:47)