Problems with FB 1.The “DO in XML” problem 2.Grammar is not full-featured a)Need query/list/index loops b)Need nested conditionals c)Etc. 3.XML is cumbersome 4.No nested layouts?!?!
Two Key Concepts Encapsulation - being self contained –FB doesn’t really do this –CFCs provide help Abstraction - separate interface from implementation –FuseDocs do this for fuses (mostly) –CFCs excel at it Both of these contribute greatly to the long-term maintainability of code.
Parts of an App Controller (UI logic) View (display) Model (business logic) HTML FB FB or CFCs Flash (inc. Flex) Flash/CFCsFlashCFCs* Web Services N/A CFCs† HTML with existing Java backend FB N/A * You can use CFM templates for this, but it’s messy † You can use FB behind a CFC façade, but that’s even messier Check out this column
So what is FB? A framework, of course, but what kind? –Application (typical use) –UI (implied by application) HTTP/text-based (definitely) Flash (not a chance) Web Services (ugly, but possible, with CFC help) What about Mach-II? Struts? Ben Hediard’s MVCF (www.benorama.com)?
What’s different? Clear distinction between action and display requests Clear distinction between UI logic and business logic Ability to “scalp” the app at any layer, and leave a functional remainder
Why is it different? FB controller circuit has ALL public fuseactions, both action and display FB can potentially combine action and display fuseactions FB’s business logic depends on the controller and it’s framework “Does this have anything to do with user interaction?”
Other benefits of CFCs Can be stateless or stateful Can easily integrate with Flash & web services Can be [nearly] transparently replaced with Java or COM Can be fully encapsulated –More effective testing –No weird assemble-time interferences Objects can provide easier/better modeling Help remove that pesky ozone layer
Why Use FB At All? Procedural nature of HTML clients FB is awesome at managing text layouts FB’s already coded, tested and functional
Weighing Frameworks I still write pure FB apps (even single-circuit ones) I never do framework-less apps Balancing current needs, anticipated needs, and overhead