Cons to Fusebox
Stace, while we wait for Dave's example apps and documentation of his development approach, I thought I'd let you know that lots of examples and framework code is available at www.fusebox.org for anyone to look at and try out. ;-) Nice to see ya again, btw. Brian Hola Dave! Any chance you'd have a small example app or what not that depicts your typical approach to developing/structuring/architecting an appplication in CF? Cheers! Stace ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=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
Cons to Fusebox
I was just giving Stace something to do while he waits for the small sample app he asked about, Dave. Dave, clearly we disagree on a fundamental level on many topics. I don't know you, but I can tell you are an intelligent person (maybe minus the sarcasm), so clearly you must have reasons for not liking Fusebox. All I can do is disagree. I tried to do it before, but now I'll make it more decisive: I'm bowing out of this discussion. I really don't like getting into exchanges like this, and it could go on for days, and I feel that the point (to get folks to examine Fusebox as an approach with many benefits) has been made. Honestly, I have better things to do. I've said my piece. Fusebox is there and ready for open consideration by anyone who has the interest in looking at it. I'll leave it to the individual reader to make their own comparisons between your common sense methodology (with all the detailed and helpful techniques you provided along with it) and Fusebox. ... Stace, while we wait for Dave's example apps and documentation of his development approach, I thought I'd let you know that lots of examples and framework code is available at www.fusebox.org for anyone to look at and try out. ;-) And why beholdest thou the mote that is in thy brother's eye, but considerest not the beam that is in thine own eye? I find it amusing that people think the use of an emoticon lets them say whatever they like without reproach. Maybe you should check your own sarcasm before pointing out mine. I think that my criticisms of Fusebox have been written clearly enough that you can understand them if you have a basic grasp of English. That doesn't mean that you have to agree with them, of course. But it does appear that you do not, in fact, have better things to do. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=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
Cons to Fusebox
I'm not going to get involved much further in this thread because just about everything has been said. Folks who don't like Fusebox still don't like it. Folks that like Fusebox still like it. Folks who don't know about Fusebox, or haven't looked at it lately, might have reason to investigate it further. And it is to those people, not the detractors or the evangalists, that my effort has truly been directed. But regarding the quote about 17,000 people, I'll say this. As with anything, looking at ONLY the number of people doing something is a poor gauge of the worth of that thing. However, the fact that far, far more people use Fusebox than any other ColdFusion methodology DOES indeed carry meaning. Why is this? What is it about Fusebox that makes it the most successful development framework among ColdFusion developers? Part of the answer is that Fusebox just works. It greatly assists one in creating a successful project. Yes, in the wrong hands, Fusebox can still allow failures. It is not a silver bullet in and of itself. But the majority of folks using it clearly are not having failures; they are having successes. It would not keep growing and improving if it were otherwise. This is due not only to the framework itself, but the general emphasis on best-practice software engineering that tends to come with the use of Fusebox. But the real benefit to having a huge, and ever growing, base of Fusebox developers, is the speed at which these developers can understand, maintain, and contribute to existing Fusebox applications. The more people who use it, the more widespread the standard becomes and the more likely development projects are to adopt it. It's a symbiotic relationship; a cycle. While some may claim that new developers can come into an existing project and instantly pick up whatever custom framework or architecture is used, I believe that in reality this happens extremely rarely. I think everyone will agree that just because ColdFusion is an easy language to understand does not necessarily mean that all ColdFusion applications are easy to understand. So to me, the real point is not that X people use Fusebox, it is that Fusebox is, by far, the most successful framework that we ColdFusion developers have. And the fact that the more people who use it, the greater the pool of developers becomes who all understand that framework and the greater the pool of projects that use it. So folks can raise their grievances about Fusebox, and it's been challenged for years by competing frameworks, but it still goes on. The community grows every day, and the number of projects using it grows as well. In the end, the only thing that matters is whether your project is a success or a failure. I submit that if you choose to use Fusebox, you are greatly increasing your chances of a successful project. Regards, Brian I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=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
Cons to Fusebox
Sorry Stace, looks like no example is forthcoming. I was just giving Stace something to do while he waits for the small sample app he asked about, Dave. Ah, I see. At least now, you're omitting the emoticon. If I say that no particular structure is needed solely to organize your CF code, why would you expect me to provide one? Why would I have a sample application to demonstrate this? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Dave, I must admit that this is the nicest and most well-formed post I've seen from you on this thread. Honestly I don't mean to seem like I'm calling you out when I support people asking for sample code from you. It's just hard for me to accept arguments from people who say there is a better way, but then won't demonstrate it. I mean, I could say the best methodology is the build the best application methodology. There are no repeatable steps to this methodology, no way to document it in a way that someone else can use. But when you use it and you do it right, whooeee the results are amazing! I'm not going to get involved much further in this thread because just about everything has been said. I think you're already involved as deeply as possible. Actually I'm serious. I'm about to bail out just out of exhaustion...have you seen how many posts I've written? ;-) (that emoticon WAS meant to be humorous) And in that case, your participation was certainly a good thing. I would strongly recommend that people take a look at anything they think might help them be better developers, with the caveat that they shouldn't believe everything anyone says, and judge for themselves. This is what I mean, thank you for that and I must admit that, in some ways, I have found it interesting, if not occasionally frustrating, to read your thoughts as well. Of course, that's just my anecdotal experience, and yours may differ. Yes, mine does. But that's OK. Anyway, sorry for the occasional heat...I can be a passionate guy. Regards, Brian ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Yeah Shawn, FB has come a ways since FB2, it's a whole lot more structured and efficient. But I confess that I fall into your second group, a person who learned HTML first and slowly got into programming. I'd like to think I've gotten pretty good at it, but there's always much to learn. It's encouraging to hear you say that you're thinking of giving Fusebox another look. It is quite easy to use CFC's as part of your Model in a Fusebox MVC application. But if you want a fully CFC-based system, Mach-II might be more your speed. Also, it's not only about whether FB gives you something that you couldn't already do in another way, because in programming, there's always 50 different ways that you could do something. It's about the fact that you can build an app in Fusebox, and then 6 months later a total stranger could pick up your code and know instantly what you did and why, instead of having to study your personal method and figure it out. That's a pretty nice benefit, especially on team projects or where long-term maintenance is a factor. Anyway, thanks for your comments. Regards, Brian My FB knowledge is a bit old (FB2 days), but what I remember is that FB basically provided a programming framework. For those of us that had a programming background (i.e. desktop applications), building a programming structure is/was a natural thing. On the otherhand, web developers without that programming background (i.e. they knew HTML, and are/were relatively new to scripting) would benifit from FB because it imposed structure on the applications they were creating. I know FB has evolved since those days, so maybe this view is outdated. From what I've seen of this thread, it might be worth looking at FB again. But now that I can build components, and basically implement OOP techniques, I don't know if FB would offer me anything that I can't already do through another method. My thoughts, not yours Shawn ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
First, I just want to be sure you understand what the fuseaction actually is. It's in the format circuit.targetfuseaction, where the circuit part is the alias of a Fusebox circuit, and the targetfuseaction part is the actual action within that circuit that you want to execute. I just wanted to make sure that was clear. So... Abstraction is one huge benefit of circuits. When I do index.cfm?fuseaction=store.productdetails, I don't know, or care, WHERE the store circuit is. This applies to both the logical and physical structure of the site. Using circuit aliases masks these dependencies because the core file handles translation of the alias to a directory path to be called. So as a team developer creating a link to that section of the site, I don't need to know anything about the application's directory structure or where that part of the site is located. On the other hand, using /root/store/products/productdetails.cfm in a link requires you to know EVERYTHING about the physical structure of the site for EVERY link. And if for some reason I refactor the site, and part of the change is to alter the physical location of my products directory, or break it up into more than one directory? Better open up a lot of files or break out the extended search and replace, because every link that points there is going to have to be changed. Circuits also allow for very easy dynamic links. If I have a component that creates a form, and I want to reuse that form in multiple places in the system but I want it to post to different things, this is really easy with circuits. You do: form action=index.cfm?fuseaction=#xfa.formAction#. Then at runtime, you can set xfa.formAction to be anything you need it to be. Bam...like magic the form can now post to any fuseaction you need it to...and you never need to touch the code itself, only set the xfa variable. Pretty much, your question goes right to the heart of why Fusebox uses circuits in the first place. The answer is that when related code is grouped together, that code is easier to maintain and change. Placing code into directories can do this as well, in fact Fusebox circuits are aliases for directories. But with circuits, you get that layer of abstraction between the alias of the circuit and it's actual path. I can tell you from real world experience that when you have to make significant changes to the structure of your application, it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. Hope that helps, Brian Mosh Teitelbaum wrote: I've been pondering the benefits and downsides of this approach for a while now. Since you bring it up, I was wondering what everyone else thought about all requests having to come in through an application spine? That is, what benefits exist and/or are perceived to exist from structuring all of your HREFs like index.cfm?fuseaction=foo.bar or index.cfm?displayPage=5 instead of /foo/bar.cfm and page5.cfm respectively? Anyone? -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=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
Cons to Fusebox
No, this is not correct. If you change the directory structure of your circuits, you don't have to change ANY of your links. When you update your circuit definition (a few lines of code), all of the aliases now resolve to the new path. And if you change your circuit NAMES, yes clearly you have to change the link. This is a much rarer situation, but if it does happen and you are properly using XFAs, you still don't have to edit a single code file. You just go into the switch (or the new xml circuit file) and alter the XFA. Yes you have to make a change, but the change is localized into a single type of file (the switch or the circuit.xml file) instead of within all the code files. I absolutely promise you, making this change with circuits is much, much easier. it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. I agree with most of your points. But if you decide to change your fuseaction names and circuits structure, don't you have to change links all over the place, plus the fusebox configuration files? (fuseaction names and circuits are also harcoded all over the place, instead of file names and directories) It solves the problem by adding another one and add complexity/overhead to your app. Always the same dilemma : when to stop to add levels/layers of abstration... :) Benoit Hediard www.benorama.com -Message d'origine- De : Brian Kotek [mailto:[EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2003 19:48 À : CF-Talk Objet : Cons to Fusebox First, I just want to be sure you understand what the fuseaction actually is. It's in the format circuit.targetfuseaction, where the circuit part is the alias of a Fusebox circuit, and the targetfuseaction part is the actual action within that circuit that you want to execute. I just wanted to make sure that was clear. So... Abstraction is one huge benefit of circuits. When I do index.cfm?fuseaction=store.productdetails, I don't know, or care, WHERE the store circuit is. This applies to both the logical and physical structure of the site. Using circuit aliases masks these dependencies because the core file handles translation of the alias to a directory path to be called. So as a team developer creating a link to that section of the site, I don't need to know anything about the application's directory structure or where that part of the site is located. On the other hand, using /root/store/products/productdetails.cfm in a link requires you to know EVERYTHING about the physical structure of the site for EVERY link. And if for some reason I refactor the site, and part of the change is to alter the physical location of my products directory, or break it up into more than one directory? Better open up a lot of files or break out the extended search and replace, because every link that points there is going to have to be changed. Circuits also allow for very easy dynamic links. If I have a component that creates a form, and I want to reuse that form in multiple places in the system but I want it to post to different things, this is really easy with circuits. You do: form action=index.cfm?fuseaction=#xfa.formAction#. Then at runtime, you can set xfa.formAction to be anything you need it to be. Bam...like magic the form can now post to any fuseaction you need it to...and you never need to touch the code itself, only set the xfa variable. Pretty much, your question goes right to the heart of why Fusebox uses circuits in the first place. The answer is that when related code is grouped together, that code is easier to maintain and change. Placing code into directories can do this as well, in fact Fusebox circuits are aliases for directories. But with circuits, you get that layer of abstraction between the alias of the circuit and it's actual path. I can tell you from real world experience that when you have to make significant changes to the structure of your application, it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. Hope that helps, Brian Mosh Teitelbaum wrote: I've been pondering the benefits and downsides of this approach for a while now. Since you bring it up, I was wondering what everyone else thought about all requests having to come in through an application spine? That is, what benefits exist and/or are perceived to exist from structuring all of your HREFs like index.cfm?fuseaction=foo.bar or index.cfm?displayPage=5 instead of /foo/bar.cfm and page5.cfm respectively? Anyone? -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription
Cons to Fusebox
Mosh Teitelbaum wrote: I can see how abstraction of a file's location might be beneficial, but I'm not sure I would agree that it's a *HUGE* benefit. It really is a big benefit. It provides security because a would-be hacker doesn't necessarily know where your file or files are actually located. However, I think this is more a form of security through obscurity rather than true security. using circuits has very little to do with security, though with Fusebox 4 you can place access modifiers on a circuit to prevent a public user from accessing it (for model and view circuits). Security through obscurity is not the point of circuits, and should always be replaced with true security. Incidentally, Fusebox 4 also has an integrated permissions system. Concerning the benefit to team development, I'm not sure I see it. You're right, the members of your development team don't need to know that the store circuit is actually a directory called MungeMe but they still need to know that they are to use the circuit named store. In essence, you're creating a virtual file system and requiring that the development team learn the virtual file system instead of the physical file system. This is not accurrate. All the developer knows is that a link or a form in the page they are working on must use an XFA varible such as xfa.submitForm. With XFA's the developer actually doesn't even know what the actual target fuseaction is. This is determined outside of the context of the individual file the developer is working on. Instead, the architect has the power to determine program flow by setting the XFA's in the switch files or circuit.xml files. And this just speaks to the development team. How does this benefit the architect(s)? The way I see it, it makes their lives more difficult because they now need to craft a physical and a virtual file system. Isn't this what the architect is SUPPOSED to do? As Benoit indicated, and as I mentioned above, you're still hard coding targets, you're just targeting the virtual file system instead of the physical one. Benoit's assessment is making the incorrect assumption that the developer needs to memorize a ciruit structure. They do not. They are given XFA variables and that's all. No knowledge of the circuit structure or the directory structure is needed at all by any developer. I'm all for reuse (actual reuse, not cut paste reuse) of code. But in practice, how often does the same one form need to be used in different situations? I can see reusing a form to add and edit a specific type of item/object but don't see reuse of a single form much beyond that. This was a simplistic example...surely you can think of instances where creating generic content components that need to respond differently in different situations would be a benefit? Practically, how often do you truly need to restructure your entire site? When your client insists that the name of the directory (or circuit) should be ShoppingCart instead of Cart, he deserves to pay a ridiculous amount of money for what can easily be accomplished with a simple search and replace. Refactoring parts of an application is an incredibly common act, in fact I would say a constantly ongoing act. It does not necessarily mean changing the name of a circuit, this happens rarely. Far more common is the act of breaking up a circuit, realizing that you've grouped too much together, or realizing that you've split things up too much, or a dozen other refactoring considerations. The point is that the logical structure of the application is totally separated from the physical structure of the application. Again, my question wasn't really directed solely at Fusebox. Nor was it meant to be any sort of swipe at FB. I'm just curious as what the practical and realized benefits and downsides are of using a central spine architecture. No problem Mosh, and no swipes or attacks are percieved. I love the chance to talk about Fusebox and understand things about it that people don't like or don't understand completely. Thanks for your views. Regards, Brian ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Dave Watts wrote: While that may be theoretically nice, why would you have so many duplicate links to the same thing anyway? A well-constructed site should have common, reusable (and potentially data-driven) navigation elements. In that light, this doesn't seem to be the huge benefit that you claim. Dave, I'm not talking about navigation elements. I'm talking about application actions, like clicking on a product to get product details, clicking a breadcrumb link to get to that page, clicking sort in a table of data to order on that column, or any one of an unlimited number of links and forms that make up a web application that are separate from global site navigation. If you really wanted that, you don't need circuits. All you need to do is create a variable to store the form action attribute, right? Maybe I'm missing something, though. There's dozens of ways to do anything in programming. The point of Fusebox is that it brings together lots and lots of these good ideas into a common framework that is easy to learn, use, and maintain. There's a whole lot of benefits to Fusebox beyond just circuits...it just so happens that circuits are what was asked about. I'll close this by stating that I'm not against your using Fusebox, or anyone else for that matter, but I did think it worth pointing out that a lot of the problems solved by Fusebox have traditionally not really been significant problems for lots of people. hmmm...well, that's OK. For me, problems are things like creating a sturdy architecture that consists of well-defined, encapsulated components, and building applications that are easy to maintain while incorporating a great number of best-practices. Fusebox is a great way to confront these problems, but it is not the only way. But using a standard like Fusebox makes is very easy to let others maintain the code, because they understand how it works. The danger with custom or secret methodologies is always the fact that before anyone can work on it they have to learn the approach used. Again, I don't think Fusebox is all-powerful...just very useful in many situations. Regards, Brian ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Matt, the point is not whether you can abstract the logical structure from your physical structure in other ways besides using Fusebox. Of course there are. But Fusebox is a standard that thousands of developer know, which in and of itself is a huge advantage. And, there are many, many more benefits to using Fusebox besides just circuits. It just so happens that circuits are one advantage of many. Sure, any one advantage of Fusebox could be replicated without using Fusebox. But when you take ALL the advantages of Fusebox together...well, if you build a system that replicates all the advantages of Fusebox and that you think is faster or easier to use, please make it public so that we can all benefit! Regards, Brian Matt Robertson wrote: Or versus this snip from a non-FB app: a href=#request.ProductsBaseHRef#processproductform.cfmlink text/a Or to stretch it a bit (too far perhaps): a href=#request.BaseHRef##request.ProductsFolder#processproductform.cfm link text/a Or this: a href=#cgi.script_name#?#client.defaultparms#blah=blahlink text/a You certainly don't need FB to standardize locations. Why would you point to something that's so simple to achieve in so simple a fashion? I can move an entire web site by a)copying the files, b)reassigning to a new dsn and c)editing a db record to change urls and physical paths. Elapsed time is maybe 5 minutes, with 3 of that being the copy process. In a simpler app this could simply go into something like application.cfm. 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=subscribeforumid=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
Cons to Fusebox
Mosh Teitelbaum wrote: OK, so let me flip this around a bit (no pun intended): In your experience, how often do you have one developer working on the form and another working on the action file? Or, more generically, how often do you have developers working on individual files instead of groups of files collectively (i.e., all of the files needed to add an item to the shopping cart)? On a small project this might not happen very often. But as a project gets bigger, or especially as changes are made to existing code, the benefits get bigger and bigger. Granted, for maintenance purposes, this might happen frequently, but in most of those cases, the issue being resolved is a code error and not a redirection update. And in the cases of redirections, the person making the fix would have to know where to redirect the request, making the whole doesn't need to know anything point moot. This isn't quite correct...the developer making changes to the code still needs to know nothing about the redirect target. That change is made to the XFA variable by the architect. In fact, if the only thing changing is the redirect, you don't even have to open the code file. Just edit the circuit.xml file (in Fusebox 4) and change the target of the XFA. On a similar note, I much prefer that my developers know the internals of a system instead of working blind. Not so much that they can make changes but rather so that they can understand the reason why things work out the way they do. Again, for a small system this might be feasable. But for large applications with hundreds of files, dozens of directories and thousands of lines of code, there is simply no way for all of the developers to know and understand all the internals of the system. Because Fusebox handles each small piece separately from the others (fuses don't know about how they are called or what happens after they are called, logical and physical structure are separate, control logic isolated in circuit.xml file, etc.) it handles large applications very nicely. Isn't this what the architect is SUPPOSED to do? I think you misread what I wrote. Whereas part of an architect's responsibility is, without a doubt, the definition of a file structure, Fusebox seems to add the additional overhead of *ALSO* having to create a virtual file structure (or more accurately, in FB terms, a series of circuits and fuseactions). So my point was that it seems to require more work from the architect instead of making her life easier. First, managing the circuit structure is incredibly easy, so it's not like this is a lot of extra work. But along with separating the logical and physical structure of the application, circuits have other advantages. In Fusebox 4, there are access modifiers. There are logical hierarchies, where settings in parent circuits can be inherited or overridden by children. You have the ability to invoke fuseactions in parent circuits without know what the parents are (similar to super() in OO). And these logical hierarchies can mimic the physical structure, or they can be totally different. There are many very useful ways to exploit a logical, hierarchical application structure that is independant of the physical structure. The point is, all of this power is in your hands when you use Fusebox and you can use as much or as little as you like. It's always there, ready for you to use when the need arises. Yes, the add/edit example was simplistic, but the application of security privileges was not. Let me give you a more fleshed out example of the security privilege dialog. Let's say I'm building a document library and I want to be able to define grant/deny privileges on whole directories or individual files. Additionally, any privileges I define on a directory can optionally be specified to cascade to the subdirectories and files contained within that directory. Regardless of whether I'm setting the privilege on a directory or on a file, the dialog itself will look the same with the exception that directory privilege dialogs have an additional checkbox concerning the cascade. In this situation, there are a few potential problems with the reuse: 1) I have to have logic in my form that, based on the object type, displays or hides the cascade checkbox. Personally, I don't have much of a problem with this example. But if we extend the example to include other systems, objects, etc. each with their own set of additional form controls, we start having problems. Not really. You'd set up different fuseactions to build different parts of the form, and call them only when you need them. If one part of the form is only used some of the time, it's only invoked and used in some of the fuseactions. Fusebox 4 has the ability to call any number of fuseactions internally, with no performance penalty, and capture the resulting output into content components that can be used later to build a final display. This is
Cons to Fusebox
OK, Dave, you're clearly of the lot who will never be convinced about the benefits of Fusebox. That's fine. But I'll go ahead and end this here so that it doesn't degenerate into a series of tit-for-tat exchanges that won't convince anyone of anything. Obviously, I disagree with virtually all of what you say as well, and we could do this for days, which I don't care to do. Everyone is entitled to their opinion. Regards, Brian Dave, I'm not talking about navigation elements. I'm talking about application actions, like clicking on a product to get product details, clicking a breadcrumb link to get to that page, clicking sort in a table of data to order on that column, or any one of an unlimited number of links and forms that make up a web application that are separate from global site navigation. Again, though, these are navigation elements. They're not global site navigation, but they shouldn't be repeated in too many places. In your example of clicking on a product to get product details, I would naturally assume that the page which lets you click on a product would be part of the same module that lets you see product details, and both pages are likely to be in the same directory anyway. The same would hold true for sortable tables, and most of the other unlimited number of links and forms that make up a web application. There's dozens of ways to do anything in programming. The point of Fusebox is that it brings together lots and lots of these good ideas into a common framework that is easy to learn, use, and maintain. There's a whole lot of benefits to Fusebox beyond just circuits...it just so happens that circuits are what was asked about. While there are many ways to do almost anything, I'm not convinced that all the ideas within the common framework of Fusebox are all that good. And, if you're trying to convince us why circuits are useful, it's not helpful to say well, Fusebox has all these other good things too! hmmm...well, that's OK. For me, problems are things like creating a sturdy architecture that consists of well-defined, encapsulated components, and building applications that are easy to maintain while incorporating a great number of best-practices. Fusebox is a great way to confront these problems, but it is not the only way. Again, I'm not convinced that it's even a great way, of course. I'm not convinced that it helps or hinders implementation of best practices. My experience with Fusebox is, at this point, pretty extensive. I've analyzed many CF applications. A lot of these were in Fusebox. I tend to find the same problems in both the Fusebox and non-Fusebox applications. Unnecessary abstraction does not count as a best practice. On the other hand, I haven't found it to be a sign of a poorly-constructed application, either. I've seen good Fusebox applications and bad non-Fusebox applications. But how well-defined and encapsulated can a component be, when it's tightly coupled to your database schema? But using a standard like Fusebox makes is very easy to let others maintain the code, because they understand how it works. The danger with custom or secret methodologies is always the fact that before anyone can work on it they have to learn the approach used. As a CF developer, I've yet to see a secret methodology, but I hear this a lot from Fusebox advocates. Here are some samples from John Quarto-von-Tivadar: Or if you're a larger shop that has a vested interest in a 'secret' methodology -- much like the people of Florence at one time gave Michaelangelo's David a FigLeaf, which only serves to create interest in what is covered up-- then any open publically known framework, Fusebox or otherwise, has to be spun a certain way since the heart of the business centers on one's 'secret sauce' ... advantages lie ... in Fusebox's adaptability to their local needs without having to customize it without creating dependencies on guruness or secret sauce. let's face it: if you're a Dinowitz or a Corfield or a Liotta, you don't *need* Fusebox, cuz you're bright and you've got a million other tricks in your arsenal. But what about the other 199,997 CF'ers? The best bet they have to get to the point where they can pick and choose the framework that suits them best is to use a known, standardized framework that solidifies sound practices. But within source code, there are no secrets - everything's there for all to see. Within a very simple language like CFML, it's even easier. The complexity often tends to lie outside of CF, anyway, and Fusebox doesn't really tell you anything except how to organize your CF code. The biggest problem I run into, when analyzing someone's application, tends to be thoroughly understanding the choices made within the data schema. Once I understand that, the rest follows pretty easily. As for guruness, I think that competence would be a sufficient substitute. A competent team of developers will not
Cons to Fusebox
I'm right with you Michael. I've heard from plenty of folks just itching for a chance to rip on Fusebox (or any topic at all, actually). But when it comes to actually delivering a superior solution, folks tend to fall suspiciously silent... I would switch from Fusebox to something else in 5 seconds if someone could present a truly superior alternative. Thus far (and I've been looking for years), no one's actually delivered. Hi, You probably hear this allot because opponents (why these exist I do not know) of Fusebox generally tout better ways of achieving the same goal. This better way is usually labeled my own methodology or the framework I've developed. Fusebox is open source and available to anyone with a desire to download it; therefore, it is open to examination and opinion. The internals of my own framework is rarely seen by the masses and such is termed secret by those defending the merits of Fusebox. My opinion on this matter is; if you have a framework you think out performs Fusebox, put it on the table and see how it holds up. I would be happy to use anything that is free, community driven, and makes my development process easier or more organized. Best regards, Michael Wilson -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2003 5:18 PM To: CF-Talk As a CF developer, I've yet to see a secret methodology, but I hear this a lot from Fusebox advocates. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=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
Cons to Fusebox
Matt Robertson wrote: 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. I'm not saying this won't work, because clearly it will. But does it take into account a hierarchy? Can your adminareahref supply settings that are automatically inherited by it's children? Or supply fuseactions that can be automatically executed when a child is called upon to perform some action? Does it allow for built-in access modifiers? 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. Can you illustrate exactly what you percieve to be 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. Again, this doesn't help me much in formulating a response. What about Fusebox is overblown? I don't think it could be much simpler: core files, configuration file (fusebox.xml), circuit files (circuit.xml). That's all there is to the framework; the rest is just application code. 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 truly appreciate anyone who is willing to objectively discuss any topic. If everyone agreed on everything, the world would be a pretty boring place. But again, when you ask if FB is worth the trouble to implement, I'm just missing what all the trouble is? Can you be specific? 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. Sounds like a great idea. Please don't hesitate (not that I think you would) to post questions here or to the very helpful community at www.fusebox.org. Regards, Brian ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Andrew Tyrone writes: The phrase use what works for you comes to mind. I don't think a lot of people that DON'T use Fusebox are opponents -- but many have credible reasons why they don't use it. I actually haven't really seen any specific things that people don't like about Fusebox...just lots of statements like it's too much trouble, or overhead, or how they can pick one thing about Fusebox and do it in a different way. And I can promise you that there are PLENTY of people that don't use Fusebox and are quite ready to attack at any time. I haven't seen much of that in this discussion, which is very refreshing. I have my own methodology and framework, and to say that people that have their own secret sauce keep it from others intentionally is ridiculous. It's like political arguments -- people just can't accept that what THEY think isn't what everyone else thinks. Also, I don't have the time to publish my framework, and I could care less if anyone thinks it's because I am keeping it from them because I think it's better than their precious Fusebox. That's fine, I wish you the best of luck with your personally-created framework. If it works for you, that is what truly matters. But when people say Fusebox is too much trouble and then my approach is better, but never actually reaveal their approach, then what can we say? How can we respond to something that we have never seen? To tell you the truth, I've seen better arguments here against using it than for using it. Again, I haven't seen a true argument against Fusebox here, other than general statements like I can do X (pick one thing) which Fusebox does on my own. So why should I use Fusebox? or Fusebox is too much trouble. These are not specific and, to me, don't constitute any argument at all. If someone can truly point out, in specific terms, what they consider to be problems with Fusebox, I'll gladly try to address them, and if necessary, admit Fusebox's limitations if the point is valid. I've also seen people get angry when others refuse to adopt it. I think the underlying psychology is they don't like what I like, so they don't like me, either. I'm not saying that about everyone that uses Fusebox, but some people are downright fanatical when other people actually give reasons and specific examples of why they don't think Fusebox is a Godsend. You would think that people like Dave Watts just came on here and said Fusebox sucks, don't use it, instead of taking the time to give their feedback on it based on real-world interaction. I've witnessed the personal attacks against a lot of people who don't use it -- just another sad attempt to discredit someone or some company that doesn't use it by stooping to levels unbecoming of a professional. I certainly know I have not acted like this, nor have I seen anyone else in this discussion behave this way. Please don't condemn the whole Fusebox community or the framework for the overzealousness of a fraction of its users. The vast majority in the Fusebox community are incredibly polity, intelligent, and eager to help. Again, if anyone has SPECIFIC issues I'll be happy to discuss them. If anyone acts in a mean-spirited way, I'll be happy to condemn them. And if anyone has an approach that they consider to be superior to Fusebox, I'll be happy to consider it. Regards, Brian ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Dave Watts wrote: I don't like controller structures, or hub-and-spoke frameworks, or whatever you want to call them. I think they add needless complexity to most CF applications. I like being able to see a URL and know which file to edit, without having to read some other file. Wow, if you can look at the URL and tell what file to edit, you must have a gigantic amount of data-layer logic stuffed into your display file for it all to be in one place. I prefer the emphasis that Fusebox places on separating logic from presentation. I don't like unnecessary use of variables at runtime. When you have something like form action=#foo#, how often does #foo# change that you need to store it in a variable? The vast majority of HTML forms are only going to post data to one place. Fusebox does not require you to use a variable for this, it's only a suggestion. And one that my experience has found to be a very useful one. I don't like unnecessary abstraction in general. You may argue that the abstraction provided by Fusebox is a better alternative than a lack of abstraction, but I haven't found that to be the case personally. If you prefer to build rigid and brittle code, I agree that abstraction is a very bad idea. I don't like (what I perceive to be) the underlying concept that web applications are like houses, built brick-by-brick, and that each of these bricks or modules needs to be as loosely coupled as possible to all the others. Not all code can be reused, not all modules are better off being as loosely coupled as possible, and in any case, such loose coupling is often impossible in fact since the data schema won't allow it. Maybe you should email the the creators of Java, or the folks who wrote The Pragmatic Programmer, any of the gang of four books, or virtually any other widely respected software engineering book, because they would strongly disagree that decoupling is a bad thing. Furthermore, I have not had any problems creating highly encapsulated modules with Fusebox, regardless of data schema. I don't like the way that Fusebox adherents tend to misuse common terms, like methodology, but that's not really a complaint against Fusebox. I do suspect that there's something to the correlation between Fusebox and its users, but I don't know what that would be. Methodology: a body of methods , rules, and postulates employed by a discipline : a particular procedure or set of procedures. This definition fits Fusebox perfectly. And I can promise you that there are PLENTY of people that don't use Fusebox and are quite ready to attack at any time. I haven't seen much of that in this discussion, which is very refreshing. Yes, the hordes of Fusebox attackers are unbearable, aren't they? It must be terrible, what with everyone constantly telling you to stop using it. I must admit that sometimes dealing with the naysayers can be quite exhausting. It's very easy to find flaws in other people's ideas. What is virtually always the case is that someone repeatedly attacks the idea without ever providing any solution that is superior (don't read too much into this if you don't want to). I have never said that Fusebox will solve all development problems. Why must you make such sweeping generalities like that? I didn't come here to convince anyone of anything, but to answer questions and then, later, to defend Fusebox from those that say it is bad but offer no better solution themselves. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. So to others out there reading these messages, I invite you to take a look at Fusebox beyond the lens of my opinion, Dave's, or anyone elses. It's free. It's wide open, sitting there and waiting for you to give it consideration, which is something very few other ColdFusion methodologies can say. Is it perfect? No. Does it solve everyone's entire set of development challenges? No. But does it openly reveal itself to anyone who wants to consider it? Yes. Is it a useful approach? Thousands of people believe it is. Does it try to incorporate the best-practice advice of many highly respected developers and software engineers, such as abstraction, encapsulation, decoupling, and orthogonality? It certainly does. Is it the approach you should take to building a web application? I strongly believe it is worthy of serious consideration, but it remains up to the individual to decide for themselves. I'll leave it at that. Regards, Brian ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for
Cons to Fusebox
Dave, clearly we disagree on a fundamental level on many topics. I don't know you, but I can tell you are an intelligent person (maybe minus the sarcasm), so clearly you must have reasons for not liking Fusebox. All I can do is disagree. I tried to do it before, but now I'll make it more decisive: I'm bowing out of this discussion. I really don't like getting into exchanges like this, and it could go on for days, and I feel that the point (to get folks to examine Fusebox as an approach with many benefits) has been made. Honestly, I have better things to do. I've said my piece. Fusebox is there and ready for open consideration by anyone who has the interest in looking at it. I'll leave it to the individual reader to make their own comparisons between your common sense methodology (with all the detailed and helpful techniques you provided along with it) and Fusebox. Regards, Brian To my mind, Fusebox takes something that is very simple - CF, a scripting language - and treats it as if it were far more complex. There's a reason that programmers using languages like Java and C# to build web applications tend to use application frameworks - those languages are comparatively hard, and you're much more likely to screw things up if you're not careful, generally speaking. If I want complexity, I might as well just use Java. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=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
Cons to Fusebox
Just a note that this problem is gone in Fusebox 4. Mike we use Fusebox heavily and the only con I have enountered (this is FB30 and CF50) is layouts render CFFLUSH unusable. Otherwise we like FB all the way. Kind Regards - Mike Brunt Original Message --- Hey everyone, Some co-workers have asked me for some pros and cons to Fusebox 4 or Fusebox in general. I polled the Fusebox list awhile back and obviously got some biased results... anyone care to chime in I guess im really looking for some cons as I have a decent list of pros. Thanks, Mike ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Again, issues like this are not present in Fusebox 4. There are no cfmodule calls necessary. We have a fairly large site, and we have begun to componentize a lot of the web controls such as select drop-down lists, partial displays, and any other functions that are useable. All these components are being called by cfmodule routed back through the index (core file), since they are organized in separate circuits. So on a large dsp page, we could have as much as 5 to 10 cfmodule calls, pulling displays, menus, and other web controls components. The overhead of the core file is now noticeable. We're using cf5. Nick Han [EMAIL PROTECTED] 07/16/03 11:20AM Hey everyone, Some co-workers have asked me for some pros and cons to Fusebox 4 or Fusebox in general. I polled the Fusebox list awhile back and obviously got some biased results... anyone care to chime in I guess im really looking for some cons as I have a decent list of pros. Thanks, Mike ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Performance in Fusebox 4 is almost 10 TIMES better than Fusebox 3. In other words, a page that took 400 milliseconds to render in Fusebox 3 takes about 40 milliseconds to render in production mode with Fusebox 4. In addition to cfflush being unuseable within FB layouts, I'll also mention that FB3 is awfully heavy to be running it as a custom tag. I've done it, and in some circumstances it's doable, but for instance, I had an application which was developed in FB3 with a separate circuit for a roles-based security model. We wanted to use the circuit as a custom tag within other circuits in order to occlude various features which were protected by the security model. Calling the circuit as a custom tag turned out to be far too costly to use that approach. Granted that this is an advanced feature of FuseBox, but it's also a potential hazard if you get a developer who comes in and sets something up that way and then you end up wondering why a whole bunch of pages are horrendously slow. I've used fusebox in the past and I can in the future if a client needs or wants. For my own development I don't prefer it. No offense to Hal and company, personally I find it slow (both development and page loads) and inflexible -- at least, that was my impression of FB3. One FB advocate friend of mine (who shall remain nameless) says it's because I'm too much of a power user (his view being that the big advantage of FB is standardization for the average developer). The best example I can give of why I found the framework slow and inflexible is this: my Tapestry CMS includes an add/remove components wizard which is much like the Windows add/remove programs wizard. It's wicked fast and allows add-on components to be installed or removed through a browser interface without modifying or overwriting any of the existing application code, without entering any file path information, and without so much as a single line of programming. It also uses cfflush to display installation progress. As a whole this couldn't have been done in FB3 without so significantly modifying the framework that I would have ended up doing more work than I did starting from scratch. I haven't looked at mach-ii yet. hth Isaac Original Message --- Mike we use Fusebox heavily and the only con I have enountered (this is FB30 and CF50) is layouts render CFFLUSH unusable. Otherwise we like FB all the way. Kind Regards - Mike Brunt Original Message --- Hey everyone, Some co-workers have asked me for some pros and cons to Fusebox 4 or Fusebox in general. I polled the Fusebox list awhile back and obviously got some biased results... anyone care to chime in I guess im really looking for some cons as I have a decent list of pros. Thanks, Mike ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
In most cases, your individual fuse files for Fusebox 3 will work without modification in Fusebox 4. However, if you want to use some of the more advanced features of Fusebox 4 (content components specifically) it may require some changes to the way you are outputting things. Furthermore, because you can execute multiple Fuseactions in Fusebox 4 without using CFMODULE and with no performance penalty, you can probably reuse some of your FB3 CFMODULE fuseactions without much change in FB4. Really, the only people who will have trouble porting to Fusebox 4 are people who grew overly-reliant on CFMODULE (who's slower performance is a CF issue not a Fusebox issue), or who intermingled too much programming logic into their displays (a symptom of deeper problems than simply a challenging conversion to FB4). You can keep on using FB3 for as long as you want, you don't HAVE to upgrade. But unfortunately in the real world, technologies have a limited lifespan. If you have a C application and you want to reap the benefits of C#, you have to recode. That's real life. Luckily, a great deal of the guts of an FB3 application will port cleanly to FB4 in most situations. Hope that helps, Brian Brian Kotek wrote: Performance in Fusebox 4 is almost 10 TIMES better than Fusebox 3. In other words, a page that took 400 milliseconds to render in Fusebox 3 takes about 40 milliseconds to render in production mode with Fusebox 4. So what happens to all the folks who hitched up their wagons to FB3? Time for a free (i.e. unbillable) do-over? How does this reflect on the cost of implementing FB3, in retrospect? Will new-cause but similar-effect issues arise in FB4? I'm anxiously awaiting fb4's release as I very much want to give it a look. Standardization is good; disciplined code is good. Torpedoed performance and a limited lifespan after adoption is terrifying. -- --- 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=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
I should have been clearer, in that the application in question used multiple CFMODULE calls to recursively call the Fusebox core and populate several sections of content. Other than the change from FB3 to FB4 (along with the elimination of the CFMODULEs), no other changes were made to the application. The processing time for an average page in this application dropped from 400 ms to 40 ms when using Fusebox 4 in production mode (a setting in the fusebox.xml file). Obviously, your mileage may vary, but I feel this is a pretty good example of the increase in performance that FB4 can deliver. Brian's comparison needs qualification. If a request takes 400ms to render, but 350 of that was a slow query, then it'll only drop to around 360ms with FB4. It's only the framework code that is enormously faster, not the application code. In my experiences, the framework overhead was annoying, but fairly small (never more than 10-15%) of total execution time. Assuming that tenfold decrease is valid (it's probably reasonable), you're only looking at shaving 10% off your total execution time. The point is that FB3 isn't horribly slower, it's the application that takes most of the time, not the framework. FB4 is has a lighter weight execution time, but it's a small difference overall. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Cons to Fusebox
Could you be more detailed, Clint? What exactly took so long? How was it 'more than you needed'? What version of Fusebox was used? How much experience have you had with it? I've been using Fusebox for years, and CF since version 3, and I've had much different results with Fusebox. Not only does it make things a whole lot easier, but when you are working on a team and you all know Fusebox, the productivity can be amazing. I recently helped on a project that used Fusebox. I tell you what.. Talk about doing more than what you need. I will never understand using Fusebox. It took more time to build the parts that I needed to get done using Fusebox than it would have had I just built it the way that I do it. I know it may work for some, but for me.. I don't like it. My 2 cents... Clint ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
CFLDAP, SSL and Active Directory
Hi All I read on Allaire's site some information about using CFLDAP with Microsoft Active Directory. I got it working, and I must say it is very cool. However, I by default all that data is moving across the network in clear text, so I want to use CFLDAP's SSL option to encrypt the traffic. Here is where the problem lies. When trying to use SSL in my CFLDAP tag, I get error connecting with server. In the Allaire article, they recommend that you install MS Certificate Services on your Acitive Directory server. This provides the server with a certificate that it can use to encrypt the traffic. So far so good. However, the CFLDAP tag, in order to use SSL, requires a path to a certificate database (usually cert7.db) to validate the authenticity of certificates. I can't make it work, and I am thinking that this is probably because the cert7.db file contains validation data for Verisign and other public cert authorities, but DOESN'T contain validation data for my MS Cert Server's credentials. My question is, if this is the problem, does anyone know how I can edit or create my own .db file to allow SSL? Or, does anyone have any other ideas? Anyone gotten SSL to work with CFLDAP while using privately-generated certificates? Thanks in advance! Brian Kotek FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
