Today we've released version 1.0 beta of the FireLadder scaffolding tool. This plugin requires DataFaucet version 1.0. We also discovered and fixed a new issue in DataFaucet while developing it, so if you alreaady have DataFaucet installed, now's a good time to update. :) And there were a couple of small issues discovered and fixed in the onTap framework core also, so while it may not be necessary, an update of the onTap core distribution wouldn't hurt either.
So you're probably wondering, "where do I download it?"
The answer - it's on the framework webservice. Just go to your onTap framework application wherever you installed it, load up the plugin manager, select the "more" tab, hit "search" and select the "install" button next to the FireLadder plugin! Find and install it directly within the framework! (Just like Eclipse! Just like Firefox!)
After downloading an extracting the onTap framework 3.2 distribution, your plugin manager can be found at:
Simply replace "localhost/ontap" for wherever you've placed the framework.
Also in case you haven't seen it yet, the installation videos on the framework home page show how to download and install plugins from the webservice.
Although this is a 1.0 release of the scaffolding utility and it is not intended for complex applications, you can expect SOA-style integration. It will create a discrete package of model objects (2 per table), an IoC Container that will be wired into the framework's manager, two views per table and a handful of controller templates.
It was actually quite a bit more complicated than I had expected and turns out to be more complicated than it is for me personally to generally just create simple CRUD apps. A large part of the problem has to do with techniques I don't normally use. For example, I don't normally change the column names in my database when I create my objects - so if I have a table with a column named "productprice", then my object has a property named "productprice" (not just "price"). I also don't create table columns with underscores in my database.
So because the DataFaucet tools recently added features to do both of these things, I found myself being forced to recreate a lot of the automation that was previously built-in to the framework core. The previous automation is still there of course, I just couldn't use it for the scaffolding tool because of the introduction of inconsistencies in naming conventions.
And then I noticed because I was using the Galleon Forums tables to test it, that I also needed a "dePluralizer" because some folks like to name their tables in the plural. This is actually a prime example of why I feel this is a bad idea. Those in favor of plural table names like "galleon_conferences" site as the reason for preferring them that you're naming the table and the table will contain multiples. Okay, that's fine. My problem with this is that this is a non-functional argument. There is no *functional* basis for it.
There are however *functional* arguments for not naming tables in the plural, notably that no matter how much you like the idea of a plural table name, you're not going to name your business objects that way. You're going to name your business objects in the singular and that means ta-da! more work on both your part and on the part of the server, simply because you felt it was "propper" to have plural table names. That's actually a *functional* argument. And you can see why if you look at the FireLadder.cfc in the new scaffolding tool, because it has to dePluralize table names... and it can't even handle all of them because they're not consistent and there aren't any rules that could be applied to distinguish when the plural is created with an "i" vs. when the plural is created with an "s" vs. when the plural is created with "es".
Status Statuses (keep or drop the e?)
Virus Virii (es or ii?)
There are no consistent rules for pluralization and therefore, no way to guarantee successful translation from singular to plural or vice versa. So the end result is that plural table names means more work and a more fragile and less scalable system.
All that being said, there is some support in FireLadder for plural table names.