Re: FuseBox vs Macromedia Programming Standards
On Thursday, August 29, 2002, at 03:13 , [EMAIL PROTECTED] wrote: For reasons that elude me, some people devote great energy to evangelizing Fusebox. When you ask them, it almost always turns out that they have never actually used anything else. Fusebox is about brainwashing developers, about advancing a particular brand of religion and so I recommend that people evaluating Fusebox ignore developers who have not actually *use* it. Couldn't resist rewording that! No offense at my gentle teasing I hope. As I have said repeatedly, I am not anti-Fusebox per se, but it does tend to live in its own little bubble and it takes words, concepts and phrases from the much larger world of IT and misuses them in a way that causes confusion. As ColdFusion moves into more mainstream programming and OO, this confusion will be particularly detrimental. On the subject of dsp files vs layout files, yes, I can see it is a powerful piece of machinery but I feel that it is more a clever contrivance made possible by the 'black box' inside the Fusebox core files than an intuitive, well-architected programming style. OTOH, I would expect that most people who use it are really only doing fairly straightforward header and footer additions with it. Note what I actually said: No, Fusebox recommends you do it and provides a well-defined way for you to do it. Fusebox itself does *not* implement this for you - you have to write your code in a very specific manner in order to do this. Fusebox again provides a *convention* for it This was in response to a Fuseboxer claiming that separation of logic and display is automatically implemented by Fusebox - it most certainly is not, the programmer still has to think about the issue and separate the code out themselves. I also said: It's somewhat contrived and, IMO, somewhat unnatural. All it's doing is forcing you to partition your code, it isn't creating a tiered architecture like MVC for example. I am not bad-mouthing Fusebox by saying this, merely trying to temper some of the wild claims made for it. My problem is not with Fusebox per se - again, I refer people to the page on my site where I discuss Fusebox - but with the wild and sometimes inaccurate claims made about it by some of the near-religious Fuseboxers. I don't think I have ever, in over twenty years of software engineering, met such fervor about a particular style of programming. People claim Fusebox saved them like it was Jesus. They jump on anyone who dares criticize Fusebox (Heretic! Heretic! Burn the heretic!). For some of them, Fusebox is no longer *a* solution, it's *the* solution. I'm one of life's natural cynics. I don't take anyone's claims at face value. As soon as my current project deadline is passed, I plan to rebuild my PHP site using Fusebox and write up my experiences. As folks ought to be able to figure out from the URLs of several pages, it already uses a style that is somewhat similar to Fusebox so I don't expect it to be a difficult conversion. The question to answer will be whether I feel the end result was worth the effort: the current site has existed in various forms for nearly seven years and has been redesigned three or four times with minimal content changes each time (originally flat HTML, then frames, then flat HTML again, then PHP wrappers). Some of those redesigns were tedious but all were fairly straightforward. I know that the PHP version I have today allows me to easily change the navigation and look'n'feel. It's very simple. We'll have to see what benefits, if any, Fusebox brings to my little site. If you're not annoying somebody, you're not really alive. -- Margaret Atwood __ 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 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
Re: FuseBox vs Macromedia Programming Standards
The official fusebox site is at http://www.fusebox.org Can anyone direct me to a brief description of what FuseBox is and how different is from the guidelines at: http://www.corfield.org/coldfusion/codingStandards.htm Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 __ 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 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
RE: FuseBox vs Macromedia Programming Standards
Mitko, The FuseBox standard is located at www.fusebox.org. You can find the FuseBox 'core files' there as well as some information as to what FuseBox is. There is also a collection of links to other sites that provide much more information about FuseBox. Another resource (which is very useful and responsive) is to check out the FuseBox discussion list at [EMAIL PROTECTED] I did not study it for details, but what I read of the coding standards link you mentioned sounds like primarily just good programming practices - i.e. naming conventions etc. FuseBox has some of this, but FuseBox is really more of a design architecture. There was a mention on the below mentioned site that separating content from layout is a good idea - FuseBox actually implements this. There was also a suggested documentation format mentioned that should be provided for each template. FuseBox is a 'generation' ahead of this by utilizing a documentation standard called fusedocs that are actually written in XML to allow for later processing. To sum up, the below link provides a lot of good information in terms of 'best practices'. FuseBox itself is a program architecture that takes those 'best practices', improves on them, and puts them into work. -- Jeff -Original Message- From: Mitko Gerensky-Greene [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 8:41 AM To: CF-Talk Subject: FuseBox vs Macromedia Programming Standards Hello, Can anyone direct me to a brief description of what FuseBox is and how different is from the guidelines at: http://www.corfield.org/coldfusion/codingStandards.htm Thanks in advance, Mitko __ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm 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
RE: FuseBox vs Macromedia Programming Standards
The coding guidelines are just that, guidelines for code. They are not a standard or the next best thing, just some general suggestions to keep your code sane. Naming conventions, some basic hard and fast rules that should be observed etc. Some of the guidelines are just things to strive for or do in code for performance reasons or common sense reasons Such as.. Readable code is more important than optimized code during application development, and probably well beyond initial development. You could follow those coding guidelines, more or less, and create something like Fusebox. That is to say coding standards are a more basic building block than something like Fusebox which carries the ideas of coding standards along with, generally, how you are going to be structuring pieces of something you develop *in* Fusebox. Jeremy __ 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 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
Re: FuseBox vs Macromedia Programming Standards
On Thursday, August 29, 2002, at 07:07 , Jeff D. Chastain wrote: I did not study it for details, but what I read of the coding standards link you mentioned sounds like primarily just good programming practices - i.e. naming conventions etc. Correct, it is a list of recommended best practices. FuseBox has some of this, but FuseBox is really more of a design architecture. It's a framework. There was a mention on the below mentioned site that separating content from layout is a good idea Indeed it is. FuseBox actually implements this. No, Fusebox recommends you do it and provides a well-defined way for you to do it. Fusebox itself does *not* implement this for you - you have to write your code in a very specific manner in order to do this. Fusebox again provides a *convention* for it - HTML generation goes in dsp_xxx.cfm files or layout files (which, confusingly, are two separate things in Fusebox), database queries go in qry_xxx.cfm files, actions (logic) go in act_xxx.cfm files. It's somewhat contrived and, IMO, somewhat unnatural. All it's doing is forcing you to partition your code, it isn't creating a tiered architecture like MVC for example. There was also a suggested documentation format mentioned that should be provided for each template. FuseBox is a 'generation' ahead of this by utilizing a documentation standard called fusedocs that are actually written in XML to allow for later processing. Again, it is a very stylized approach, requiring users to learn a specific way of documenting code (which is not necessarily a bad thing) and it still doesn't help ensure that the documentation actually matches the code. I won't argue with the benefit of being able to automatically generate documentation from code - which Fusebox effectively lets you do - but this is an idea that's been around since the 60's so it's nothing new. ColdFusion MX supports this directly by generating Javadoc-style output from the code itself which means that the documentation can *never* get out of sync with the code, unlike Fusedocs. To sum up, the below link provides a lot of good information in terms of 'best practices'. FuseBox itself is a program architecture that takes those 'best practices', improves on them, and puts them into work. Fusebox is a framework, not an architecture, and whether it improves on various best practices is a point of much contention. http://www.corfield.org/coldfusion/codingStandards.htm See also: http://www.corfield.org/coldfusion.phtml?cfsection=coldfusion/fusebox If you're not annoying somebody, you're not really alive. -- Margaret Atwood __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. 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
RE: FuseBox vs Macromedia Programming Standards
Might I jump on this post and add a little? Don't mind if I do. With the CF and Java worlds now closely coupled I think it becomes critically important to begin using the proper terminology for what things are in the software development world. Honestly web developers/programmers are not exempt from using proper terminology in the first place. I am not naming anyone for doing this, but an architecture, a framework, and a methodology all have well understood meanings in software development. You really can't just use these terms interchangeably. Maybe I am just beating a dead horse here, but I still see grossly misapplied, misleading terminology bantered about on various CF lists rather often. I an not a language nazi or a perfectionist. I really hate when people will accuse other programmers of being an academic simply because that person strives to do things correctly, not even perfectly, just correct. No, I'm not your 3rd grade grammar teacher who will correct you every time you misuse a term. Just based on context, honestly, you can't always tell what something really means. If you dig and look deeper you usually can gain enough contextual information and concrete data to determine what something is. However, for improved communication with the other development communities proper terminology from the start is important. Without communication there can be no transfer of knowledge. Here is how terms get improperly spread throughout a community or group of users: Someone might slightly misuse a term once. And someone else seeing the term slightly misused might take that term in its context and try to determine its meaning. Next that person who tried to figure out what the word meant begins misusing the term due to an incomplete understanding of the term to begin with. Pretty soon you have several levels of indirection that lead to people using terms in a completely new way that does not match with how most of the software industry uses the term. It is just all around bad soup. Some common sense logic applied to trying to join some new group or community and become an accepted member: You have to learn that groups rules and etiquette before you can interact in a manner that will be viewed as completely acceptable by that group. And you have to interact with a new group to really become known and accepted within that group. I know these kind of things seem trivial, and nearly academic, points. When it comes right down to it a lot of trivial and academic points can add up to have a serious impact on things the every day web developer will face from day to day. Anyhow, I will stop off my soapbox now. Jeremy __ 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 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
Re: FuseBox vs Macromedia Programming Standards
There's actually an excellent reason for distinguishing between display files and layout files. Layout files are applied AFTER the display files. These act like a skin. In fact, skins (called layouts in FB3) can be nested. Say that we have a site with a directory structure like this: MyApp -- Admin -- Users The fuseaction Users.new might create a generic form. Then the directories, Users, Admin, and MyApp, all can apply a skin in Chinese doll fashion: Users wraps the login form; Admin wraps that and then MyApp wraps that. This can be turned on/off for individual layers. In addition, because the layout presentation is applied after the content is generated, the layout chosen can be determined based on what occurs in the content. This provides a great deal of power and allows presentation to be quite separate from content. For reasons that elude me, some people devote great energy to bad-mouthing Fusebox. When you ask them, it almost always turns out that they have never actually used Fusebox. Fusebox is about empowering developers, not about advancing a particular brand of religion and so I recommend that people evaluating Fusebox talk to developers who actually *use* it. Original Message: - From: Sean A Corfield [EMAIL PROTECTED] Date: Thu, 29 Aug 2002 11:00:45 -0700 To: [EMAIL PROTECTED] Subject: Re: FuseBox vs Macromedia Programming Standards On Thursday, August 29, 2002, at 07:07 , Jeff D. Chastain wrote: I did not study it for details, but what I read of the coding standards link you mentioned sounds like primarily just good programming practices - i.e. naming conventions etc. Correct, it is a list of recommended best practices. FuseBox has some of this, but FuseBox is really more of a design architecture. It's a framework. There was a mention on the below mentioned site that separating content from layout is a good idea Indeed it is. FuseBox actually implements this. No, Fusebox recommends you do it and provides a well-defined way for you to do it. Fusebox itself does *not* implement this for you - you have to write your code in a very specific manner in order to do this. Fusebox again provides a *convention* for it - HTML generation goes in dsp_xxx.cfm files or layout files (which, confusingly, are two separate things in Fusebox), database queries go in qry_xxx.cfm files, actions (logic) go in act_xxx.cfm files. It's somewhat contrived and, IMO, somewhat unnatural. All it's doing is forcing you to partition your code, it isn't creating a tiered architecture like MVC for example. There was also a suggested documentation format mentioned that should be provided for each template. FuseBox is a 'generation' ahead of this by utilizing a documentation standard called fusedocs that are actually written in XML to allow for later processing. Again, it is a very stylized approach, requiring users to learn a specific way of documenting code (which is not necessarily a bad thing) and it still doesn't help ensure that the documentation actually matches the code. I won't argue with the benefit of being able to automatically generate documentation from code - which Fusebox effectively lets you do - but this is an idea that's been around since the 60's so it's nothing new. ColdFusion MX supports this directly by generating Javadoc-style output from the code itself which means that the documentation can *never* get out of sync with the code, unlike Fusedocs. To sum up, the below link provides a lot of good information in terms of 'best practices'. FuseBox itself is a program architecture that takes those 'best practices', improves on them, and puts them into work. Fusebox is a framework, not an architecture, and whether it improves on various best practices is a point of much contention. http://www.corfield.org/coldfusion/codingStandards.htm See also: http://www.corfield.org/coldfusion.phtml?cfsection=coldfusion/fusebox If you're not annoying somebody, you're not really alive. -- Margaret Atwood __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. 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
