I wish you the best of luck with the FB4 book. I think you'll be very pleasantly surprised.
I used to manage settings in exactly the same way you describe. I started using FB2/XFB and slowly stopped doing it, because FB took care of a lot of those problems for me. However, it didn't all come easily. I hacked up the XFB "core files" (they weren't fully abstracted at that point) to get out of circuit aliases, because I didn't see the point, and it was extra, meaningless processing. Then I had a long email discussion with someone (maybe Steve Nelson?) about it, and changed my mind. The processing wasn't a big deal, the aliases made URLs nicer, and forced me to name things intelligently, rather than half-assing it like I had frequently been doing. By the time FB3 came about, I was all over it, and actually implemented my own XML format for my circuits definitions, very similar to how FB4 does it now, because I didn't like building the layout directly in CF structures. I've been all over the FB4 beta releases, and had my share of issues with it's architecture. Most of those ended up being caused by fundementally flawed thinking on my part. I was set in my ways, and while generally good for the tools I had, moving to a new tool magnified the until now unnoticed flaws in them. Now that I'm familiar with FB4, architecting and managing applications is a snap, much easier than with FB3, and the sky's the limit. FB4 is purely procedural (intentionally so), but I'm seeing a much better integration with a CFC-based model from FB4 than I saw from FB3. Nothing to do with the framework itself, but the shift in thinking that using FB4 prompted me into. Some one's gonig to beat me with a stick for mentioning Benoit Hediard's MVCF framework again, but it's also a very good one. It is similar in many was to Jakarta Struts, which is not for CF, but after playing with some JSP/Servlets for a project, a lot of that carries over nicely. However, I'm still a fusebox guy, and probably always will be. FB4 is extensible enough (a lot of people's biggest issue with FB3) that you can easily make use of other architecting styles, without having to choose one or the other. Grab a piece here, grab one there, and you can make "fusebox" into pretty much anything you want, but still reap all the benefits it provides. cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com > -----Original Message----- > From: Matt Robertson [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 17, 2003 3:27 PM > To: CF-Talk > Subject: RE: Cons to Fusebox > > > Barney (and Brian), my comments inline below: > > Barney wrote: > >Think about how many request variables you're going to need to manage > >for a decent sized application with numerous modules. > > OK here goes: > > baseHRef, > ImageHRef, > AdminAreaHRef > SecurebaseHRef, > SecureImageHRef, > SecureAdminAreaHRef > BasePath > ImagePath > > Multiply that by two (in the db ONLY) as my system keeps separate > values for dev and live servers. A cfif in application.cfm > decides which server it is running on and converts the relevant > value to a request var, which is used everywhere. > > Since a web site can have different sections, the db record > described above is repeated for each of them. Naturally this db > record holds a bunch more stuff than just url values. On a > good-sized site there are maybe 5-10 such sections. Of course > I'm caching the settings record query. > > To me this seems simple, efficient and easy for another developer > to figure out if I get hit by a bus or something. > > >Wouldn't it be nice to have a framework that'll do all that for you? > > See above. > > >Especially one that's been proven effective and has great community > >support, rather than something homegrown? > > Well, there's the rub I think. Is FB *that* much better that I'm > willing to take the good with what I perceive to be the bad. > I can't escape the conclusion that the bar seems awfully steep to > solve some basic issues whose solutions in turn are themselves > simple enough. I guess if I could boil it down what I'm feeling > when I look at FB is its goals are all laudable but its just flat > out overblown in toto. > > >I hate having this argument, because everyone (myself included) > has such a > >strong opinion, and nothing will sway anyone. > > Not necessarily. I may not be agreeing, but I am listening > carefully to both you and Brian. I really want to like FB and > have an industry standard framework to adhere to. That all > sounds wonderful... but the question is whether FB is worth the > trouble to implement? > > I've pre-ordered the FB4 book and, when I find the time (the > learning curve is at least half the problem, I think) I'll try > and implement it on my GridMonger tool. Thats a wonderfully > functional doodad that is just horribly laid out; the result of > its origins as a very very simple wizard-generated whatsit. Sean > needed a project (http://corfield.org) to work on to get a true > feel for FB and so do I. > > -- > ------------------------------------------- > Matt Robertson, [EMAIL PROTECTED] > MSB Designs, Inc. http://mysecretbase.com > ------------------------------------------- > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
