CFCs are the Framework
This CFC framework is too simple for you. It has too much power without enough work. It doesn’t even have a really clever name. Frankly, you’re not going to like it.
But in case you’re still curious, you can download my presentation, the codebase and a 5 page code walk through here:
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!
Comment by Peter Bell — February 5, 2007 @ 12:00 am
Peter, remind me to finish my million dollar story the next time we meet up.
WRT including in a cfc, honestly it makes no difference to me (unless you’re working on one of my projects), nor to this cfc framework. It’s merely architectural style; everything will work exactly the same (assuming you keep track of var’ing variables).
Comment by Steve Nelson — February 5, 2007 @ 12:00 am
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!
Comment by Peter Bell — February 5, 2007 @ 12:00 am
Sure, that’s perfectly fine. You can still use my asinine CFC framework. It doesn’t affect anything.
You might consider rethinking this approach with HTML. But… you don’t have to. If you’re nuts, you can put all the HTML in the CFCs. It’ll still work.
Comment by Steve Nelson — February 5, 2007 @ 12:00 am
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.
Comment by Peter Bell — February 5, 2007 @ 12:00 am
Well there you go. Include those html files in CFCs and you gain all the benefits of CFCs and improve the consistency of the overall application.
Comment by Steve Nelson — February 5, 2007 @ 12:00 am
Hey Steve, great concept. I’ve began to toy around with it myself. Is there a reason you chose application.cfm over using cfc?
Comment by shane montgomery — February 6, 2007 @ 12:00 am
Steve, one more question, why did you stick the URLToken and ID in a cfcookie? I noticed Expires=Never, what’s the reason for this. I’d imagine you would want the token and id to die after the session?
Comment by shane montgomery — February 6, 2007 @ 12:00 am