Frameworks Conference: CFCs ARE the Framework, by Steve Nelson
CFCs ARE the Framework, by Steve Nelson
As before - excuse the scattered nature of this review as I'm writing while listening.
Talking about the rise of frameworks in the CF community. He asks if frameworks are necessary, and they are, and he makes the good point that which one you use isn't as important as ensuring the entire team is using the same framework. (Definitely ditto that.)
What Steve likes: MVC and Teamwork. What he doesn't like: Using XML. He describes it as two languages doing the same thing. (I definitely disagree here. But more on that later.)
He doesn't like the core files in most frameworks. Says it adds complexity and you have to rely on other people's code.
So what about CFCs simply managing themselves? So first - he uses Application.cfc to store a whole crap load of components in the Application scope. (In the onApplicationStart of course.) He separates his CFCs into model, view, and controller CFCs. He parses the controller and method to call from the URL. (So if foo.doit, the controller is foo, and the method is doit.) Then he invokes the component/method.
The controller CFC is very simple - just shells out to the model or view depending on the method being run.
He uses includes in his CFC methods which led to a lovely debate. I (along with Sean, Doug, others) argued that this was bad since it made it easier to have var scope issues. Steve made the point that the whole var scope thing was an Adobe bug, and while I agree that var scoping is a pain, it doesn't mean we can ignore it.
So all in all - it seems like this whole thing is simply an organization to his CFCs. I guess I get that - and it is better than not using any organization at all - but as a whole, I don't think I would use this approach. I don't see a particular URL for his framework, but here is Steve's blog: http://www.webapper.net/. (I just noticed that he mentions on his blog that the code will be released later.)
One quick note - Steve did show a nice little trick. He has a cflocation abstraction that, when in development, can show debug information and a link to the URL. In production it just runs the cflocation. That's not a bad little development tool.
p.s. Steve says to look at http://labs.webapper.net.
Comments
I have to agree with Steve, stick with CFC's I cant rely on someone elses unspported framework.
I like CF & CFC's as they are stable, if I have a problem, I know it's not Coldfusion, I know it's my code, once you start using frameworks you loose that confidence.
Ray, thanks for your helpful presentation on Model-Glue. It's one of the ones I got a lot out of.
I've not looked too much at the code yet, but it seems the Application scope would very easily end up just as a mess of CFCs.
"Steve made the point that the whole var scope thing was an Adobe bug"
That's not what Macromedia told me during the (CF7) beta. Thay said it was a feature, and more over some people are relying on the behaviour and so it wasn't going to be fixed.
I'm hopeful it'll be an option in CF8, along a with one to ban output from CFCs without having to write output="false" on them all.
Failing that, I'm going to hunt down the people using the broken variable leaking stuff in their code and talk at them till they stop :-)
Dale: I'm not so sure I understand this. The code is open source and CFML. If Joe were to die, it's not like the code would stop working. :)
@Steve - hey, we're developers, wouldn't you expect us to argue semantics?! Hehe well anyway, I will probably hop over to your blog (assuming you posted it) and check out the presentation because it sounds interesting.
Though FB2 doesn't have any core file, but it was much powerful than some other frameworks which has a complete set of core files.
The idea that Steve brings out this time really give me a glance. When I read his idea in a blog, I said "Wow, why didn't I think of that?".
The FB4 feature which means most to me is the <do /> syntax. It's really usefully, especially to architect the application with MVC approach.
As all of you might know, <do /> is for invoking another fuseaction within a fuseaction. Before FB4, FB3 did the similar job by FuseQ.
Before Steve's idea comes out, I just thought the <do /> feature could not be done well without XML config & parse. Therefore, I felt comfortable to rely on the FB4 core files as long as I can enjoy this feature. But, when Steve points out the CFC way, I thought we were re-inventing the wheel in some senses.
For FB5, the new features: lexicon and fuseaction-wide variable scope (there might be some other) can be accomplish by Steve's idea without any extra effort. For example, when using <cffunction> tag, we can use whatever cf-tags we want. But when using <do>, we have to pre-define lexicon.
"If we can do it as good in pure CF, why do we need the core files?". That's my curious.