Objective Action - CodeGeneration

onMissingMethod and Abstract Objects

Mon, 26 Jan 2009 20:48:00+0100

I have finally got around to working a bit more on the fusebox scaffolder project. One of the things I have meaning to do was improve the generated code by using an abstract bean and letting generated beans inherit some base methods. I intend to do this for most of the generated cfcs, but just started with the bean as a first step. I have not in the past used onMissingMethod but now enough of what I am doing is on CF8 that I decided it was worth incorporating in the generated code. I began by reading up about it to see what others had done. There was certainly lots of ideas out there and I decided to take John Whish's dynamicAccessors.cfc and take it a bit further. John's idea was to make use of the <cfproperty> tag to set up the properties in a cfc and then to make use of the onMissingMethod in a base cfc to create dynamic accessors. I really like this idea but I also like Peter Bell's idea for controlling the access to the getters and setters through a list of property names. I was wondering about combining the two ideas and remembered somthing I discovered in the early days of CFCs. You can actaully create your own attributes on many of the CF tags just by adding them to the tag. So I can write:

and ColdFusion will ignore my two new attributes in most respects. What it will do is add them to the metadata so I can read them. This allows me to extend John's getAccessors() method to update two new structures one for the setters and one for the getters.

I now have two new structures in my object which I can use to test if the generated code should allow you to set or get each property. A small change to the onMissingMethod() function and I can now control who has access quite easily. What I really want to know is: Am I mad to do this? After all I am arbitarily extending the language and I didn't ask anyones permission. 27Jan 16:25 GMT - Modified to fix a couple of typos.

Fusebox Beta and Alpha releases

Tue, 02 Oct 2007 09:06:00+0100

Yesterday at MAX Sean Corfield announced the release of Fusebox 5.5 Public Beta. There is a new page on the Fusebox web site with links to all the modules. One of the modules vailable on the beta page is my scaffolding code which is not strictly a Beta as its currently in Alpha. If you would like to take part in Alpha testing please let me know. I am keen to see people using the tool to generate applications and to get as many of the bugs as possible in the current code tracked down before we start adding the features for the next Alpha 2 version which should include some other databases. Sean has also put the Fusebox 5.5 release notes on Share so demostrating the usefulness of the new service.

Tutorial on Code Generators

Mon, 12 Feb 2007 18:06:00+0100

Todd Sharp has posted the first of a series of blogs on Code Generators. The first article features the Illudium PU-36 Code Generator by Brian Rinaldi.

Domain-Specific Modeling

Sat, 10 Feb 2007 10:41:00+0100

There is a good article on Domain-Specific Modeling in the Microsoft Architecture Journal. I am interested to know if anyone is using this kind of technology with ColdFusion. Is there a similar open source tool available for drawing Domain-Specific Models?

1:45 pm Peter Bell - Application Generation - Beyond Scaffolding

Thu, 01 Feb 2007 19:40:00+0100

Peter spoke about: Language Oriented Programming which can allow you to create more reusable code. What is required to build a code generator. Software product lines can be used to deliver projects in certain cases. Look at way to generate a web application. Scaffolding will automatically generate code to create forms, lists and view pages for an object. It is typically done by using the database to provide the metadata. Eg Reactor. There are limits to what can be done that way. User has to add extra code later to make up for the limitation of the database metadata. Language Oriented Programming is a new approach to programming which improves the metadata. Everyone is doing it: OMG: Model Drive Architecture. Microsoft: Sofware Factories. JetBrains IntelliJ Meta Programming system. CF Custom Tags or UDFs are ways to do some similar things. Modify the language to create a domain specific language. CFCs do this too.... The reason is to encapsulate complexity. Layered software allows you to create a domain specific language to solve the problems. Good programmers often begin with a pseudo-code to describe the problem then replace the code with real calls to real routines. Horizontal DSLs: SQL,
Reg_Ex,
Objects,
Notifications,
ColdSpring XML,
Reactor XML. Vertical DSLs:
Newetter,
Insurance Quotes
Three types of DSL:
Declarative,
Templating,
Scripting. Declarative languages are ideal for reuse. Templating languages simplify for designers. Scripting languages are used to implement the solution. What vs How It really does not matter which language gets used. ColdFusion, XML, Special, Diagrams. There are three types of code generator: Passive (not much use),
Active (easier),
Roundtrip (difficult).
Metadata can be stored in text files, XML or a database. The code can be generated using a templating language. Eg XSLT or ColdFusion. CFTemplate can be used. Iterator is required: One DAO per object, one template per screen etc. Orchestrator is required: described by Metadata. You will never generate everything because it is quicker to handle separately, eg Safe code snippets or Inheritance. Anatomy of a generator: Metadata, Templates, Iterator, Orchestrator, Extensions. Need to be able to generate the code in minutes. Use a feature model and allow wizards to select features. There is an object model and an interface model. Content
@LiveDate: Optional: Datetime: 1/1/2000
@Status: Required: Status: approved
Use custom data types to describe the interface model. Screens can be defined by:
@Type=List,
@Paging=Yes,
@RecordsPerPage=50. Layer software product lines for higher levels of reuse. CFGen and CFTemplate will be available at http://www.pbell.com in the next few weeks.

10:15 am Chip Temm - Model driven development and code generation

Thu, 01 Feb 2007 16:13:00+0100

Tooling required for model driven development to create code and database from the model. The presentation was forward looking, presenting ideas where not much code exists yet to do this kind of thing in CF. Quality is important and the goal is repeatable success. Process is important and should be about developing software rather than to fulfil a management objective. Documentation is used to pull together the Design, Development and Maintenance process. The code documentation is a big challenge, which developers don't like to do. Using the model to generate the code allows the model to be seen as a key step in the process. Multiple projects and moving from project to project means the developers will need to move to new projects and the knowledge evaporates. Is the code clear? Do we need to design documents? Modelling the metadata will communicate the design. You can use reflection to extract the component metadata. The designs can be copied into other projects and improve the productivity of programmers. Generating code framework will allow the work to be distributed to multiple developers. Forward generating code is easier when you have the whole model available. Refactoring can be made easier. ColdFusion is a difficult language to parse. The generator can also generate unit test tools. Tools Overview: Most UML modelling tools now support code generation, Java is the target and CF is not supported out of the box. Adalon has support for Fusebox 4. Most tools export to XMI and some have extended XMI. Tigris.org Argo UML Free; has a facility to create templates. Sparx Systems Enterprise Architect - $200 : Goodvalue Gentlesoft Poseidon - $900 (based on Argo UML) Choices: Use the XMI and create your own generator. As an example 2MB file for two classes with a few methods. Most is related to the diagram. So it pays to focus on the model. Use the tool to define the metadata and generate XMI, which can be used to create the code. The tool will not contain the CF datatypes. You may have to create a package and create CF datatypes in that first. You can use XSL templates to convert the XMI or use ColdFusion to create the generator. www.cfopen.org has an experiment called open model to try and do this. The code there is not production quality. There is also a cfcXMI plugin for Poseidon which create class files for the app using the model. Sparx has better templating but nothing for CF yet. Converting code to models (round tripping): Code needs to have reliable metadata. (Not type = "any") Define properties with to allow it to know about the properties. Challenges: Some tools have support for PHP. We need to show support for CF in these tools. Round tripping CF is hard because it is not XML compliant. Flex should be easier because it is XML and Poseidon already supports Actionscript. Fear of wizards. Persistence methods are easy to generate but custom methods are difficult or impossible to generate. Investment cost issues. How many people I there to change? What will the tools cost? What is the risk of change? Presentation Links