Peter Bell For Dummies : DSLs, Application Generation, and more.
Web Development
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:
- 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 ____.
- 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.
Many thanks for the posting - was great to meet you and I think this is a really good summary of what Domain Specific Languages and code gen are all about. Of course, there are more benefits than just being able to use different programming languages.
Because you’re expressing what you want the code to do more DRYly (Don’t Repeat Yourself) and concisely, it is easier to make changes.
Let’s say a client wants to add a “middle initial” to the user object. So, you go into db and add a column. You then add getMiddleInitial() and setMiddleInitial() to your bean. You then add middle initial to some of your SELECT statements in your queries and you add the display of it in a number of your views and a field for editing it into some or all of the forms for editing it. You could do that. I’d rather just add one line to my XML and hit the “regenerate” button to do almost all of that for me (some custom coded views would have to be modified by hand but the rest can be done pretty well automatically). How much time would that save?
Also, horizontal changes (across your app) are much easier to implement. Lets say you have a big contact management system with all kinds of forms and views that contain a bunch of phone numbers (work phone, work fax, cell, home phone, home fax, secretaries phone, etc.). Let’s pretend it is US only and ignores extensions. Right now your phone numbers are varchar(20)’s with a simple, single text box for editing. Boss comes in “no good, different formats, not professional” - upshot – you have to replace single box with three small boxes, strip out all non-numerics from the entered data and validate that it is 10 characters, and add code in your views to wrap the 10 digit output consistently as (xxx) xxx-xxxx. I have the concept of custom data types. I have the code for displaying, processing and editing a phone number in one place that gets used by all the phone numbers. I could make this change in 2 mins – 10 with testing. How long would it take if you had 300 different places where a phone number was either displayed or edited?
It’s all about building and maintaining better web apps in less time. Great posting though - many thanks!
@Peter: aren't you considering creating some kind of documentation or maybe a book that explains and teaches this topic. Somethin that maybe starts by first introducing one to the concept of application generation, then to the intermediary level and further to the advanced aspect of it.
@ Fro: What kind of stuff are you generating? Are just you using it to create your bean, dao, gateway, service? Or are you taking it beyond that, like creating forms, db scripts, [insert cool generated stuff here] ?
As for what to generate, bear in mind there is NOTHING you can't gen - only things that aren't worth the effort of generating. I generate forms, default views, value lists, workflows, notifications, validations, transformations, controllers, all kinds of stuff. Much easier than having to do it by hand!
Loading....