CFCs are the Framework

Hey Steve,

Just wanted to say had a great time meeting you at the conference. Your Foosball kung-fu is strong, but my Air Hockey skills will bring down you and your little framework too :->

Cool idea re: the framework. I'd still add ColdSpring (or LightWire) for easier mocking while testing and in general simpler replacement of objects based on deployment requirements. I also like to abstract all my cross cutting concerns and that is really easy using DI and AOP (you can just mix in decorating methods on object instantiation).

I also like to write the code within my CFC (no reason NOT to cfinclude, but I don't have a good reason TO cfinclude - except for views which I handle using CFCs that include processed templates stored as CFM files).

As mentioned by the audience, var scoping and custom tag calls might bring some benefits, and for me the killer opportunity missing from this is the use of base classes with methods for implementing code that it similar across business objects, for DRYer code and better reuse, but other than that, this looks pretty similar to what I'm doing with LightBase.

Will be interesting to see feedback from others, but whatever happens, as usual you seemed to have managed to skillfully manage good ideas and just a little bit of trash talking to make for an excellent presentation - definitely one of the best at the conference!

Looking forward to the second installment it was quite a story - very cool!

I personally keep everything within CFCs (as opposed to cfincludes) as I often break down into smaller methods and even used composed objects and it is easier to do that style of coding by keeping everything except for the layout templates within the CFCs. Find I can reuse more granular snippets of code by composing objects to provide richer behavior than the core CF tags and can also wrap advice around method calls to do stuff like logging via AOP, but as you said - mainly a matter of preference!

I put the HTML in cfm templates that are actually generated based on a custom templating language we use (very minor differences to CF) and parse to keep our graphic designers from getting into too much trouble. However, all of the actual coding is done in cfcs including stuff which is a pain for designers like concatenating the HTML for paging through a list of records x records per page - that way designer can just %Display.paging()% and have the paging HTML generated without uglying up their template.

Hey Steve, great concept. I've began to toy around with it myself. Is there a reason you chose application.cfm over using cfc?