Ok, so I need to get something off my chest. Reading Peter Bell (and now that I finally met him in person, listening to him) makes me feel a little dumb sometimes. I can clearly understand that he is speaking English, but sometimes it feels that I must have just skipped that day in word-learning class.

I have been intrigued by his application generation topics since he first started blogging just over a year ago, and until recently it was more of a mystical fantasy world that only Peter Bell had access to. Now, hopefully I am not too far off target in my understanding but I think things are beginning to sink in and light bulbs are beginning to click on in my head.

DSLs
Domain Specific Language? What the heck?! Just when I thought I was getting a handle on more advanced topics in CF, people (not just Peter by the way) have to start kicking this one around. The way I understand it, DSLs are a way to describe, lets say, your model. In other words, we should be able to describe the objects in our system without introducing the specifics of how this code will look in whatever language your application is generated in (ha! I am talking about generating applications).

Basically this concepts aids in  separating What you mean, from how you say it.

For example: Lets say we want a Person object, and for this example I will use XML to write the DSL.
<objects>
<object  name=”Person”>
<attributes>
<attribute name=”FirstName”>
<length value = “50”/>
<type value = “varchar”/>
<default value = “”/>
</attribute>
<attribute name=”LastName”>
<length value = “50”/>
<type value =  “varchar”/>
<default value =  “”/>
</attribute>
<attribute name=”DateTimeUpdated”>
<length value =  “”/>
<type value =  “datetime”/>
<default value =  “Now”/>
</attribute>
</attributes>
<relationships>
<relationship name=”Group”>
<type value =  ”OneToMany”/>
<key value =  “GroupId”/>
</relationship>
</relationships>
</object>
</objects>

Now, obviously this is very simple and just written on the fly (literally…I am on an airplane right now), but it should show that we are describing things about this Person object without saying anything about a programming language that will eventually be used.
This example might look slightly familiar if you have used any of the ORM frameworks, that is because their configuration files are a good example of a DSL.

So, Ok I have an XML document that details every last object in my system, so what? Well, one thing that I know I lose sight of is that there are other programming languages out there in this world (or so I’ve heard) and we may want to document our model language agnostic, so that if we ever need to generate this application in some other, more inferior, language we could.

Two things that this application generator are going to do is:

  1. Create the model – in our case the bean, DAO, gateway, service. In my case, it would be all CFC’s, but what if you wanted Ruby or .Net or ____.
  2. Generate database creation scripts. Another good example of why we want to create generic documentation about our objects. We will need to create different db scripts based on the DBRMS of our choice.

Hopefully I am not dumbing this down too much, but I am positive I am still missing some of the major concepts that Peter Bell has been laying down on this topic. But I think the general idea, is that we create this meta-data about our objects and then use that information to generate code/db scripts/etc using our “Translators” “Generators” etc for our specific needs or language.

So, to extend just our basic model, table creation concepts. Lets say we now need to document functionality in a way that avoids being language specific.

Maybe as part of our object definitions we might have a functions node:
<object name=”Person”>
<attributes>
<attribute />
</attributes>
<methods>
<method name=”Authenticate”>
<validate attribute=”Firstname”/>
<validate attribute=”LastName”/>
</method>
</methods>
</object>
(Obviously we probably wouldn’t need a way to authenticate a Person by their first and last name, but I just stayed with the same object we talked about above. )

So, in this case could assume that we translate this new optional method node and create a method in our PersonService.cfc perhaps called “AuthenticatePerson” or maybe just “Authenticate” whatever. If you decide to read up on Peter’s stuff on extending a Base class, we could use a generic method called “authenticate” and since we are passing in the things to validate against, it would be easy to create a generic Authenticate method.

If you want to find out more on this topic, be sure to check out Peter Bell’s Blog on Application Generation.