Sorry if anyone's been waiting, with baited breath, for this instalment. I had intended to post once a week. However, life intrudes on these plans. So, while I will try and stick to a weekly instalment, there will be no guarantees.OK We've decided what we want to do. Now, how do we start going about it?
In this post, I will review what happens in the various frameworks when you create a project:
This runs a script that generates a ruby project framework for your application under the folder named 'Enchant'
Before proceeding to look at the results, I would like to comment that I long ago concluded that Tolkien had some sound advice for programmers: 'Do not meddle in the affairs of wizards! They are subtle and quick to lead you down the garden path before abandoning you behind the compost heap with all the fairies'.
What I mean by that should become clear when I describe the project structure that rails creates:
Hello? Are you still there? I'm not surprised if you found all that a bit daunting. It is a bit of overhead for a simple 'hello world', isn't it?
Of course, you don't actually have to know the ins and outs of *all* these directories before you start doing some work, but it serves to show that Wizards, while thay may do a lot of useful things for you, become less useful when you actually start having to do your own work, and try to figure out what it is that they have actually done for you. (Look up 'Guru' as an anti-pattern). In fact, this tree has even more detail than I have shown, but I think the point is made, even without drilling further down into the depths of the directories, api/, public/, and vendor/.
Anyway, the folders we do need to concentrate on are:
- app/: this is where the bulk of the application code will be placed. It is organised into sub-folders in a fairly intuitive way:
- models/: for classes describing the application data models
- views/: for classes handling the output displays
- controllers/: for classes that handle the action prompts, interrogate the model, and return the appropriate view
- helpers/: for classes that assist at the small-scale
- script/: this contains a lot of useful utility scripts for maintaining and developing the project. You'll see these in use shortly.
- vendor/: for third party software. By 'third party', I would include common code you develop and maintain yourself for use in multiple applications.
By comparison, the structure that Django creates is laughably simple:
$ django Enchant
Whether this naive setup allows for good scaling, or is only good for naive applications, remains to be seen.
It is not immediately obvious how to set up a Cake project. Certainly, there is no 'Cake' me a baked project command. There does appear to be an underlying assumption that you operate with one cake application per server, so all you have to do is install Cake and get going in the 'apps' directory. The directory structure of cake appears to suggest this, and is similar to the Rails structure. Guess you have to copy the template to where you want it. (Was I grumbling about Wizards earlier?)
Next... Doing something visible.