> Let me also say this, I know who you are, and I know that > you are eons above where I am in coding ability.
Heh, heh. Don't say that until you've had to maintain my code! I've written my share of bad code. However, the big advantage that I have over the average CF programmer, I think, is that I get to work with a lot of other people's code. I do a lot of maintenance and code review, so I get to see what works and what doesn't. In my experience, Fusebox hasn't made any difference there, one way or another. > However, if you are saying that FB is not a methodology > then you are wrong. I guess that we differ on what it means to be a methodology. I'll address this below in more detail. > FLiP "tells you how to organize the development process". > Now I don't think that XP needs to tell you how to > organize your classes. That's inherent. With CF it's not. Oh, but you're wrong about that. You have to figure out how to organize your classes; you have to figure out what entities you need to represent, and you need to figure out how those entities need to interact. This is hardly a trivial process, and is much more complex, in my opinion, than code organization within CF. It's complex enough that a specific vocabulary has built up around it: design patterns, anti-patterns, refactoring, etc. In OO programming, it's all about organization. In procedural programming, this issue doesn't come up in nearly the same way. > I still see sites all the time where you go from folder > to folder, pointing directly at whatever.cfm and there is > no organization. Perhaps so, but this seems like something that could be addressed by common sense. Let's say, a rule that each directory will have a default document (like index.cfm) and each directory will be a separate application module. There! > Just a quick step back from this. I think we are getting two > separate parts of FB confused. Fusebox 3 is a framework. It > is a way to organize and write your code to make it easier > to maintain and follow. FLiP is a "methodology" that covers > the development process. OK. Why do the two need to be considered part of a single whole? By the way, I couldn't find anything about "FLiP" on fusebox.org, which isn't very helpful. > Now for a lot of the CF shops out there, methodology or > process was non existent. You wrote a page with links going > were they needed and then you wrote the page it linked to > and so on. There was no real flow. Spaghetti code. FB 1-3 > helped with this. It cleaned it up. It let people know > where to look for something, and it made following the > app a lot easier. This is more of a statement about the sorry state of web application development than about the need for Fusebox. Given that a lot of web developers didn't come from a programming background, I can understand this. However, that's not much of a defense. > Now for definition time: As long as it's not clobberin' time! > Mature: It has time. People have been using for several > years, and it has grown. This is a field in which maturity isn't so easily bestowed. Java, for example, is thought to be immature by quite a few people. Considering I can't find a definitive source for complete, thorough and adequate documentation, I'd dispute the maturity of Fusebox. > Open: Anyone can crack open the core files. make changes, > suggest changes to the standard. OK. That's fine, I guess. What's the process for submitting changes to the standards committee? Who's on the working group for the spec? > standards based: following a standard. In this case there is > a standards document that outlines what the core files should > do, not how it should be implemented For the life of me, I can't find this document anywhere. I've seen various application implementations, which differed in many respects. But I've found nothing which is a standard, in the "standard sense" of the word. For example, if I want to know anything at all about the HTTP protocol, or SOAP, or HTML, or XML, there are many sources of information, but only one standard for each. The standard is definitive - it doesn't matter what the books say, if they disagree with the RFC. > methodology: A body of practices, procedures, and rules > used by those who work in a discipline or engage in an > inquiry (taken from dictionary.com) The problem with dictionary definitions, in this respect, is that they don't define terms of art within a field. Within the scope of the English language, the word "methodology" has the generic meaning you've listed. Within the programming field, it has a more specific meaning. If you're not familiar with that meaning, and you want to be a programmer, it would be worth your while to do a little research on the topic. I'm not trying to be flippant by suggesting that. After all, that's what I did. I wasn't formally trained as a programmer, and I had to slog through all that stuff on my own. (See the very first point at the top.) Along the way - and I'm not at the end yet, of course - I've learned a lot of things about application development that way, and it's been very valuable. One of the things I've learned is that a little bit of perspective does wonders - if you watch long enough, you'll see the same problems solved over and over again! Now, finally, because I'm very tired, I'd like to just state in closing that my opinions are my own - I'm not going to say "don't use Fusebox" or even "Fusebox is bad" - I just don't feel that strongly about it one way or the other; I don't feel as strongly about it as Matt does. However, I would suggest that if you're relying on Fusebox to determine how to structure your applications, you should learn more about the topic of application development. (Even if you don't rely on Fusebox, you should learn more about that topic, right?) You may find that you no longer care about the issues that Fusebox addresses, because you'll have discovered a new set of issues that may be more important to you. My sole complaint about Fusebox is simply that it obscures those issues for a lot of programmers, who then focus on what I consider to be less important and rather mundane issues - I've heard too many times, "well, the application is written in Fusebox, so what problems could it have?" Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
