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.
Archived Comments
To be fair to Steve, we all hyped this thing up by all the debate over XML config v. API conventions and Steve was led like a lamb to the slaughter. He was quite willing to be thrown into the lion's den however, but he made some concessions from the very beginning about it only being an experiment.
Sorry,
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.
Steve's link above has flash tutorials and sample files. As one scouting for an alternative to FB3 and learning and being coupled to one of the XML-based frameworks, I liked its simplicity.
Ray, thanks for your helpful presentation on Model-Glue. It's one of the ones I got a lot out of.
This approach feels like Rails, and I don't like their idea of having object names and methods in the URL - too easy for someone to change.
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 :-)
Tom: My point to Steve was, whether or not it is a bug or intended behavior, you just can't ignore it.
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. :)
I didn't see this presentation, but from how you've explained it, it sounds like Steve is teaching a methodology not a framework. Were there core files in the framework? Or was it primarily a set of rules? I consider that to be the main difference between the two.
I saw a few files for support, but if I remember right, there was only like 1-3 of them. It mostly seemed to be a set of rules.
I agree Rachel, Steve was discussing a methodology and not a framework. However, if he called it "CFC's ARE the methodology", he wouldn't be invited to speak at the frameworks conference...
Ray - May Joe live long and prosper :)
Ray, can you send me a link to your var scoping tool you made a while back? I still think it would be relatively easy to extend it to handle included templates. Don't you? I'll add the functionality to it if you're up for it.
Aaron, years ago i used to get into a lot of trouble for mix and matching the words methodology and framework. It was such a common complaint that i started mix and matching them on purpose just to cause trouble.
/me gives Steve the "Thumbs Up" for causing trouble.
@Aaron - very true!
@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.
Steve, look here.
oops:
http://ray.camdenfamily.com...
Rachel, the methodology that Steve was discussing makes me recall the FB2 era. FB2 was no framework but a methodology/concept.
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.