Andromeda: Give it a chance

I have been working with Andromeda for well over a year now and I can honestly say that I love this framework! I have tried many other frameworks including the following:

• Mach II (ColdFusion)
• FuseBox (ColdFusion & PHP)
• Joolma (Not necessarily a framework)
• MyCMS (PHP) developed by jeff@madtasty.com

And I have always found a reason that I could not use the framework in the fashion it was intended. I guess this is because alot of framework take the MVC approach and try to separate the business logic from the display logic. The MVC approach can cause a very large headache when you are picking up somebody elses' project and they are no longer around to answer questions. It also can cause a little bit of a headache because in my option it tries to be too organized. So I have never really used a framework for any given project because once I have started on these projects I have found the need to modify the framework in such a way that now what I have made exists outside the framework.

Now going back to the MVC approach, its definetly a good idea on paper however in the site/application is still just file based. So in the end instead of looking in say one object file you are looking in about 2,3,4 or even more places just to add a field to the page.

In my opinion Andromeda takes an MVC type approach and separates the business logic from the code completely, and puts it in the database. All your business rules go into the database and now the database does the validation, so you can never have invalid data.

Andromeda uses YAML to define the database and the rules. An example of this would be:

table contacts:
 module: addressbook
 column name:
     primary_key:"Y"
     description: Name
     tooltip: Persons Name
     uisearch: "Y"
 column add1:
     primary_key: "Y"
 column add2:
 column city:
 column state:
 column zip9:

The above creates a table called contacts with 6 column: name, add1, add2, city, state, zip.
Andromeda has predefined columns. I have used only predefined columns in the table above, but sya you wanted to create another field to store the contacts favorite food, you could achieve this in the following way:

column favorite_food:
 type_id: vchar
 description: Favorite Food
table contacts:
 module: addressbook
 column name:
     primary_key:"Y"
     description: Name
     tooltip: Persons Name
     uisearch: "Y"
 column add1:
     primary_key: "Y"
 column add2:
 column city:
 column state:
 column zip9:
 column favorite_food:

You now have defined a column "favorite_food" that can be used in any other table in your application. Now once we build our application this table will exist in our application and can be edited right away with 0 code. One of the things I love the most about Andromeda is that it created the CRUD (CReate, Update, Delete) screens for you, with 0 code so any time you might have spent creating these screens is no longer needed and if you go back and look at my table definition you'll see there is a property called "module". This allows us to assign permissions groups for each of these modules. This is done in the following way:

group editors:
   description: Address Book Editors
   module addressbook:
       permsel: "Y"
       permdel: "Y"
       permins: "Y"
       permupd: "Y"

This defines a group called "editors" and gives it SELECT(permsel), DELETE(permdel),INSERT(permins), and UPDATE(permupd) permissions to any table in the module address booke. OK I am sure by now you are asking "but how does this put the business logic in the database?" OK lets say we now want to be able to assign phone number to these contacts we can now add a couple more tables to allow for this.

group editors:
    description: Address Book Editors
    module addressbook:
        permsel: "Y"
        permdel: "Y"
        permins: "Y"
        permupd: "Y"
column favorite_food:
    type_id: vchar
    description: Favorite Food
table contacts:
   module: addressbook
   column name:
       primary_key:"Y"
       description: Name
       tooltip: Persons Name
       uisearch: "Y"
   column add1:
       primary_key: "Y"
   column add2:
   column city:
   column state:
   column zip9:
   column favorite_food:

table phonetypes:
    module: addressbook
    column name:
        primary_key: "Y"
        uisearch: "Y"
        description: Phone Type
        tooltip: Phone type eg. Cell, Home, Work

table contactnumbers:
    description: Contacts Phone Numbers
    foreign_key contacts:
        uisearch: "Y"
        primary_key: "Y"
    foreign_key phonetypes:
        primary_key: "Y"
        uisearch: "Y"
    column phone:

We've now added two tables(phonetypes & contactnumbers). The phonetypes table is extremely simple and allows us to add phone types such as Cell, Work, Home, etc...

The contactnumbers table has foreign_keys to the two previous tables contacts & phonetypes and that will tell the system that the primary_key fields from those tables need to be included in this table and to also make the primary_keys for this table. Our CRUD screens we will also have a drop down list for the foreign_key entries and this is done again with 0 code. What these primary_keys do is restrict each contact to having one phone type for each contact. If you try to insert more than one phone number for each phone type for a given contact, whether it be through the CRUD screens or even the SQL command line you will get an error telling you that the record already exists. So you don't have to make sure the record exists before you try inserting it, its done for you...yes of course you can still do this just so that your application wont have a DB error thrown back but the benefit of this is you can never get more than one phone type for a given contact into the system.

Now say for instance you wanted to have the number of phone number for each contact included in the contact record, you can have this done in the database for free with what Andromeda calls AUTOMATIONS. Here is how this is achieved:

column num_phones:
    type_id: int
    description: Number of Phone Numbers
table contacts:
    module: addressbook
    column name:
        primary_key:"Y"
        description: Name
        tooltip: Persons Name
        uisearch: "Y"
        column add1:
        primary_key: "Y"
    column add2:
    column city:
    column state:
    column zip9:
    column favorite_food:
    column num_phones:
        automation_id: COUNT
        auto_formula: contactnumbers.phone

Once again we've added another column definition(num_phones) and now you'll notice the automation_id property of COUNT and the auto_formula of contactnumbers.phone this tells Andromeda to do a count of records in the contactnumbers table that reference this table as a parent table(foreign_key). This is only a tip of the iceberg when it comes to Andromeda. There are many other useful automations and features such as ranged primary keys and dominant records.


This entire article is my opinion and probably not that well organized but I highly suggest taking a look at this "Database Development System/Framework". My basic examples above do not even compare to what is possible with Andromeda. It does sometimes take changing the way you approach certain things but in the end you will have drank the coolaid realized why you will never use another framework again.

I would highly suggest joining the mailing list and sending an email if you think something cannot be approached in the way you like. I have found more than once that the way that I like isn't the best way.

**Comments are welcomed and appreciated, even if you don't agree**