fusebox style: too much disk access?
I was reading on the fusebox concept of putting minute modules into separate files and the question is: wouldn't that slow the site by having to access too many different disk files to load one page? Cyrill Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Re: fusebox style: too much disk access?
Cold Fusion server tried to keep all template in cache memory in compiled P-Code. It only checks the time stamp on the file, and if you set "Trusted Cache" it doesn't even make that check. At 01:00 PM 10/19/00 -0700, Cyrill Vatomsky wrote: >I was reading on the fusebox concept of putting minute modules into separate >files and the question is: wouldn't that slow the site by having to access >too many different disk files to load one page? > >Cyrill > > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message >with 'unsubscribe' in the body to [EMAIL PROTECTED] --- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 x204 Fax 1.212.545.0938 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
A simple test of included files suggests that CF's internal file access functions were pratically built with a cfinclude-heavy architecture in mind. Accessing dozens of files for a single page request is very quick. Out of 100 included files, you might notice a 10 ms increase than if you had all the code on the same page. Now that 10 ms performance hit gives you a scalable, intelligible architecture. If you have any experience with really large sites, you know that the only safe way to scale a project is to break it into small "minute modules". All this is without mentioning CF's ability to cache templates automatically. Accessing a file from RAM is basically instantaneous. If code scalability, readability, longevity, and understandability is important now or will be important later, you need to adopt a structured application methodology like Fusebox. Nat Papovich ICQ 32676414 "I'm for truth no matter who tells it." -Malcolm X, 1965 -Original Message- From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 1:00 PM To: CF-Talk Subject: fusebox style: too much disk access? I was reading on the fusebox concept of putting minute modules into separate files and the question is: wouldn't that slow the site by having to access too many different disk files to load one page? Cyrill Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
The performance hit is nearly undetectable. Don't worry about it. -- Mark Warrick Phone: (714) 547-5386 Efax.com Fax: (801) 730-7289 Personal Email: [EMAIL PROTECTED] Personal URL: http://www.warrick.net Business Email: [EMAIL PROTECTED] Business URL: http://www.fusioneers.com ICQ: 346566 -- > -Original Message- > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 19, 2000 1:00 PM > To: CF-Talk > Subject: fusebox style: too much disk access? > > > I was reading on the fusebox concept of putting minute modules > into separate > files and the question is: wouldn't that slow the site by having to access > too many different disk files to load one page? > > Cyrill > > -- > -- > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists > or send a message with 'unsubscribe' in the body to > [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebarRsts or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
Here is the reason CFINCLUDES are things to not really worry about :) Like most sane languages there is a phase of interpreting /compilation (to Pcode in this case) called preprocessing. In Preprocessing you would include any CFINCLUDES making all of your cfincludes one template. So it takes the merest of moments for CF to preprocess the file and even in some cases it is already in PCode and there is no need to recompile. So after the preprocessing phase it begins the actual interpreting portion. In fact (GCC as an example) has a seperate program called cpp which is "C preprocessor" basically this file expands any macro's includes and include files and prepares the program to actually be compiled. CF does things much the same way so this is why its really not a factor for the small hit it costs, the gains in terms of ease of use and code writing are well worth it. Jeremy Allen [EMAIL PROTECTED] -Original Message- From: Warrick, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 4:53 PM To: CF-Talk Subject: RE: fusebox style: too much disk access? The performance hit is nearly undetectable. Don't worry about it. -- Mark Warrick Phone: (714) 547-5386 Efax.com Fax: (801) 730-7289 Personal Email: [EMAIL PROTECTED] Personal URL: http://www.warrick.net Business Email: [EMAIL PROTECTED] Business URL: http://www.fusioneers.com ICQ: 346566 -- > -Original Message- > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 19, 2000 1:00 PM > To: CF-Talk > Subject: fusebox style: too much disk access? > > > I was reading on the fusebox concept of putting minute modules > into separate > files and the question is: wouldn't that slow the site by having to access > too many different disk files to load one page? > > Cyrill > > -- > -- > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists > or send a message with 'unsubscribe' in the body to > [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=sts or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Re: fusebox style: too much disk access?
Don't be confused by what Nat is saying, a single "fuseaction" in a Fusebox application may only hit 5-8 files. It's really not that big a deal. Steve Nat Papovich wrote: > > A simple test of included files suggests that CF's internal file access > functions were pratically built with a cfinclude-heavy architecture in mind. > Accessing dozens of files for a single page request is very quick. Out of > 100 included files, you might notice a 10 ms increase than if you had all > the code on the same page. Now that 10 ms performance hit gives you a > scalable, intelligible architecture. If you have any experience with really > large sites, you know that the only safe way to scale a project is to break > it into small "minute modules". > > All this is without mentioning CF's ability to cache templates > automatically. Accessing a file from RAM is basically instantaneous. > > If code scalability, readability, longevity, and understandability is > important now or will be important later, you need to adopt a structured > application methodology like Fusebox. > > Nat Papovich > ICQ 32676414 > "I'm for truth no matter who tells it." > -Malcolm X, 1965 > > -Original Message- > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 19, 2000 1:00 PM > To: CF-Talk > Subject: fusebox style: too much disk access? > > I was reading on the fusebox concept of putting minute modules into separate > files and the question is: wouldn't that slow the site by having to access > too many different disk files to load one page? > > Cyrill > > > > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a > message with 'unsubscribe' in the body to [EMAIL PROTECTED] > > > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message >with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
A single "Fuseaction", as Steve mentions may hit a minumum of 5-8. The last (very large) project I worked on routinely called 30 or more files for a single page request. We thought it was great! All those files means debugging is a breeze, site updates are easy, and creating new functionality is oftentimes just a matter of cfincluding already existing files. As Mr. Mark Warrick said - "The performance hit is nearly undetectable. Don't worry about it." Nat Papovich ICQ 32676414 "I'm for truth no matter who tells it." -Malcolm X, 1965 -Original Message- From: Steve Nelson [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 3:23 PM To: CF-Talk Subject: Re: fusebox style: too much disk access? Don't be confused by what Nat is saying, a single "fuseaction" in a Fusebox application may only hit 5-8 files. It's really not that big a deal. Steve Nat Papovich wrote: > > A simple test of included files suggests that CF's internal file access > functions were pratically built with a cfinclude-heavy architecture in mind. > Accessing dozens of files for a single page request is very quick. Out of > 100 included files, you might notice a 10 ms increase than if you had all > the code on the same page. Now that 10 ms performance hit gives you a > scalable, intelligible architecture. If you have any experience with really > large sites, you know that the only safe way to scale a project is to break > it into small "minute modules". > > All this is without mentioning CF's ability to cache templates > automatically. Accessing a file from RAM is basically instantaneous. > > If code scalability, readability, longevity, and understandability is > important now or will be important later, you need to adopt a structured > application methodology like Fusebox. > > Nat Papovich > ICQ 32676414 > "I'm for truth no matter who tells it." > -Malcolm X, 1965 > > -Original Message- > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 19, 2000 1:00 PM > To: CF-Talk > Subject: fusebox style: too much disk access? > > I was reading on the fusebox concept of putting minute modules into separate > files and the question is: wouldn't that slow the site by having to access > too many different disk files to load one page? > > Cyrill > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Re: fusebox style: too much disk access?
All I have to say is that I want to see the app where the client complains about a 3 millisecond hit. I think that is where I show them my Broadvision prices. Welcome back guys. Sean Renet. ps, did "funky ass results" make the book? :::reaches for his checkbook::: - Original Message - From: "Steve Nelson" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, October 19, 2000 3:23 PM Subject: Re: fusebox style: too much disk access? > Don't be confused by what Nat is saying, a single "fuseaction" in a > Fusebox application may only hit 5-8 files. It's really not that big a > deal. > > Steve > > Nat Papovich wrote: > > > > A simple test of included files suggests that CF's internal file access > > functions were pratically built with a cfinclude-heavy architecture in mind. > > Accessing dozens of files for a single page request is very quick. Out of > > 100 included files, you might notice a 10 ms increase than if you had all > > the code on the same page. Now that 10 ms performance hit gives you a > > scalable, intelligible architecture. If you have any experience with really > > large sites, you know that the only safe way to scale a project is to break > > it into small "minute modules". > > > > All this is without mentioning CF's ability to cache templates > > automatically. Accessing a file from RAM is basically instantaneous. > > > > If code scalability, readability, longevity, and understandability is > > important now or will be important later, you need to adopt a structured > > application methodology like Fusebox. > > > > Nat Papovich > > ICQ 32676414 > > "I'm for truth no matter who tells it." > > -Malcolm X, 1965 > > > > -Original Message- > > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, October 19, 2000 1:00 PM > > To: CF-Talk > > Subject: fusebox style: too much disk access? > > > > I was reading on the fusebox concept of putting minute modules into separate > > files and the question is: wouldn't that slow the site by having to access > > too many different disk files to load one page? > > > > Cyrill > > > > -- -- > > > > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a > > message with 'unsubscribe' in the body to [EMAIL PROTECTED] > > -- -- > > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] > -- -- > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Re: fusebox style: too much disk access?
Okay, I'm not concerned with cfincludes and those related issues. I am concerned with the handling of multiple requests on the index or "fusebox" page (i.e.) a single page. For example say I have 1,000 users on my site. If they are all accessing index.cfm as opposed to 20 to 30 different .cfm pages. How does this affect caching and does it produce any other problems. Thank you, Don Sparks not quite at the 32nd chamber of fusebox. - Original Message - From: "Steve Nelson" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, October 19, 2000 3:23 PM Subject: Re: fusebox style: too much disk access? > Don't be confused by what Nat is saying, a single "fuseaction" in a > Fusebox application may only hit 5-8 files. It's really not that big a > deal. > > Steve > > Nat Papovich wrote: > > > > A simple test of included files suggests that CF's internal file access > > functions were pratically built with a cfinclude-heavy architecture in mind. > > Accessing dozens of files for a single page request is very quick. Out of > > 100 included files, you might notice a 10 ms increase than if you had all > > the code on the same page. Now that 10 ms performance hit gives you a > > scalable, intelligible architecture. If you have any experience with really > > large sites, you know that the only safe way to scale a project is to break > > it into small "minute modules". > > > > All this is without mentioning CF's ability to cache templates > > automatically. Accessing a file from RAM is basically instantaneous. > > > > If code scalability, readability, longevity, and understandability is > > important now or will be important later, you need to adopt a structured > > application methodology like Fusebox. > > > > Nat Papovich > > ICQ 32676414 > > "I'm for truth no matter who tells it." > > -Malcolm X, 1965 > > > > -Original Message- > > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, October 19, 2000 1:00 PM > > To: CF-Talk > > Subject: fusebox style: too much disk access? > > > > I was reading on the fusebox concept of putting minute modules into separate > > files and the question is: wouldn't that slow the site by having to access > > too many different disk files to load one page? > > > > Cyrill > > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
> Okay, I'm not concerned with cfincludes and those related > issues. I am concerned with the handling of multiple requests > on the index or "fusebox" page (i.e.) a single page. For > example say I have 1,000 users on my site. If they are all > accessing index.cfm as opposed to 20 to 30 different .cfm > pages. How does this affect caching and does it produce any > other problems. I'm not a Fusebox fan, by any measure, but it won't hurt performance at all to access one file a thousand times, as opposed to accessing a thousand files once each. The "native" instruction set within the file will be cached within the CF server's memory. In any case, the other files will still be used as needed, just from within index.cfm rather than as separate requests from the browser. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
Wouldn't that be the same concept as 1,000,000 people hitting Yahoo's homepage and search script every day? I think what it comes down to is that a properly built application on a server capable of handling those kind of requests is not going to have any problems with the Fusebox methodology of coding. ---mark -- Mark Warrick Phone: (714) 547-5386 Efax.com Fax: (801) 730-7289 Personal Email: [EMAIL PROTECTED] Personal URL: http://www.warrick.net Business Email: [EMAIL PROTECTED] Business URL: http://www.fusioneers.com ICQ: 346566 -- > -Original Message- > From: Donald Sparks [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 20, 2000 8:45 AM > To: CF-Talk > Subject: Re: fusebox style: too much disk access? > > > Okay, I'm not concerned with cfincludes and those related issues. > I am concerned with the handling of multiple requests on the > index or "fusebox" page (i.e.) a single page. For example say I > have 1,000 users on my site. If they are all accessing index.cfm > as opposed to 20 to 30 different .cfm pages. How does this affect > caching and does it produce any other problems. > > Thank you, > Don Sparks > not quite at the 32nd chamber of fusebox. > > - Original Message - > From: "Steve Nelson" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Thursday, October 19, 2000 3:23 PM > Subject: Re: fusebox style: too much disk access? > > > > Don't be confused by what Nat is saying, a single "fuseaction" in a > > Fusebox application may only hit 5-8 files. It's really not that big a > > deal. > > > > Steve > > > > Nat Papovich wrote: > > > > > > A simple test of included files suggests that CF's internal > file access > > > functions were pratically built with a cfinclude-heavy architecture in > mind. > > > Accessing dozens of files for a single page request is very quick. Out > of > > > 100 included files, you might notice a 10 ms increase than if you had > all > > > the code on the same page. Now that 10 ms performance hit gives you a > > > scalable, intelligible architecture. If you have any experience with > really > > > large sites, you know that the only safe way to scale a project is to > break > > > it into small "minute modules". > > > > > > All this is without mentioning CF's ability to cache templates > > > automatically. Accessing a file from RAM is basically instantaneous. > > > > > > If code scalability, readability, longevity, and understandability is > > > important now or will be important later, you need to adopt a > structured > > > application methodology like Fusebox. > > > > > > Nat Papovich > > > ICQ 32676414 > > > "I'm for truth no matter who tells it." > > > -Malcolm X, 1965 > > > > > > -Original Message- > > > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, October 19, 2000 1:00 PM > > > To: CF-Talk > > > Subject: fusebox style: too much disk access? > > > > > > I was reading on the fusebox concept of putting minute modules into > separate > > > files and the question is: wouldn't that slow the site by having to > access > > > too many different disk files to load one page? > > > > > > Cyrill > > > > > > > -- > -- > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists > or send a message with 'unsubscribe' in the body to > [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebarRsts or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Re: fusebox style: too much disk access?
> I'm not a Fusebox fan, by any measure, Why not? What would need to be changed to make you a fan? Steve but it won't hurt performance at all > to access one file a thousand times, as opposed to accessing a thousand > files once each. The "native" instruction set within the file will be cached > within the CF server's memory. In any case, the other files will still be > used as needed, just from within index.cfm rather than as separate requests > from the browser. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > voice: (202) 797-5496 > fax: (202) 797-5444 > > > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message >with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
> > I'm not a Fusebox fan, by any measure, > > Why not? What would need to be changed to make you a fan? I'd have to be working on applications where the complex logic is stored in CF, instead of in other application tiers. I don't want to fuel another "Is Fusebox good or bad" thread, but I don't think it fits well with the type of applications that we focus on here at Fig Leaf, which typically have lots of client-side complexity, like frames, JavaScript, Flash, etc. and have lots of application logic within other application tiers on the server-side, like within stored procedures or COM/EJB. On the other hand, if I was working on an application with all of its complexity within CF, I'd probably like Fusebox quite a bit. Once you move most of that complexity from CF to other tiers, though, Fusebox doesn't do much for you, in my opinion. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
What-evah, Dave. Fusebox kicks ass for the very implementation you mention. COMs can be called from a single file (using a new prefix com_filename.cfm if you want), then whenever you need that COM, you cfinclude that file. Maybe it would help us if you made a distinction between application logic encapsulation and business rules encapsulation. If you do both within COM/EJB, then you practically don't even need CF for anything other than CFOUTPUT. If however, you want application logic in COM, but still want business rules in CF, then Fusebox is great. No? It seems to me that if you remove application and business logic from CF, then a structured application architecture (like Fusebox) becomes less of a necessity. What kind of CF architecture do you guys use in EJB/COM-heavy apps? Nat Papovich ICQ 32676414 "I'm for truth no matter who tells it." -Malcolm X, 1965 -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 10:12 AM To: CF-Talk Cc: '[EMAIL PROTECTED]' Subject: RE: fusebox style: too much disk access? > > I'm not a Fusebox fan, by any measure, > > Why not? What would need to be changed to make you a fan? I'd have to be working on applications where the complex logic is stored in CF, instead of in other application tiers. I don't want to fuel another "Is Fusebox good or bad" thread, but I don't think it fits well with the type of applications that we focus on here at Fig Leaf, which typically have lots of client-side complexity, like frames, JavaScript, Flash, etc. and have lots of application logic within other application tiers on the server-side, like within stored procedures or COM/EJB. On the other hand, if I was working on an application with all of its complexity within CF, I'd probably like Fusebox quite a bit. Once you move most of that complexity from CF to other tiers, though, Fusebox doesn't do much for you, in my opinion. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Re: fusebox style: too much disk access?
it's not really a question of it's good or bad, it's a question of what is it missing? I've seen a ton of Fusebox code with everything you've mentioned below. It ROCKS for Frames, here is a presentation on it: http://www.fusebox.org/Files/presentations/FuseboxandFrames.ppt Javascript works great with Fusebox, even psuedo-javascript for browsers like Avantgo, just name your files with a "JS_" prefix for files that contain nothing but JS, or put JS code directly in your display files. It's that simple. Flash is cake, Fusebox is used both when sending requests back to the server which not really too much different than regular HTML connects, and use dsp files for calling the flash movies and act files when changing data back on the server. COM/EJB this is again a judgment call on what you name the file that makes the COM or EJB requests and what it does. COM and EJB can do a ton of different things so it's just a matter of naming conventions for the fuse that calls the COM objects or EJBs. That's it. Stored Procedures "qry_" files if the SP is getting data from the DB, or "act_" files if the SP is changing data in the database. In either case, it doesn't really matter what you name the file, it's just not going to have any display to your user, so separate that CFML code from the display CFML. It's not meant to be a standard for all the languages you can plug into CF, just for when calling CF pages. It's just a bunch of naming conventions and solutions to common problems. If your problems aren't solved by the current solutions, offer new ones that's the whole idea! Still not convinced? Drink beer with me at the conference, I'd love to chat more! love ya Dave! K:-) Steve Dave Watts wrote: > > > > I'm not a Fusebox fan, by any measure, > > > > Why not? What would need to be changed to make you a fan? > > I'd have to be working on applications where the complex logic is stored in > CF, instead of in other application tiers. I don't want to fuel another "Is > Fusebox good or bad" thread, but I don't think it fits well with the type of > applications that we focus on here at Fig Leaf, which typically have lots of > client-side complexity, like frames, JavaScript, Flash, etc. and have lots > of application logic within other application tiers on the server-side, like > within stored procedures or COM/EJB. > > On the other hand, if I was working on an application with all of its > complexity within CF, I'd probably like Fusebox quite a bit. Once you move > most of that complexity from CF to other tiers, though, Fusebox doesn't do > much for you, in my opinion. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > voice: (202) 797-5496 > fax: (202) 797-5444 > > > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message >with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
Since we're talking about it... I always thought that breaking up an application by "type of activity in the file" like dsp for display and qry for query didn't make sense. I want to break up my application by logical "object" like a user profile, an inventory item, etc.. At 11:19 AM 10/20/00 -0700, Nat Papovich wrote: >What-evah, Dave. Fusebox kicks ass for the very implementation you mention. >COMs can be called from a single file (using a new prefix com_filename.cfm >if you want), then whenever you need that COM, you cfinclude that file. > >Maybe it would help us if you made a distinction between application logic >encapsulation and business rules encapsulation. If you do both within >COM/EJB, then you practically don't even need CF for anything other than >CFOUTPUT. If however, you want application logic in COM, but still want >business rules in CF, then Fusebox is great. No? > >It seems to me that if you remove application and business logic from CF, >then a structured application architecture (like Fusebox) becomes less of a >necessity. What kind of CF architecture do you guys use in EJB/COM-heavy >apps? > >Nat Papovich >ICQ 32676414 >"I'm for truth no matter who tells it." >-Malcolm X, 1965 > > >-Original Message- >From: Dave Watts [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 20, 2000 10:12 AM >To: CF-Talk >Cc: '[EMAIL PROTECTED]' >Subject: RE: fusebox style: too much disk access? > > >> > I'm not a Fusebox fan, by any measure, >> >> Why not? What would need to be changed to make you a fan? > >I'd have to be working on applications where the complex logic is stored in >CF, instead of in other application tiers. I don't want to fuel another "Is >Fusebox good or bad" thread, but I don't think it fits well with the type of >applications that we focus on here at Fig Leaf, which typically have lots of >client-side complexity, like frames, JavaScript, Flash, etc. and have lots >of application logic within other application tiers on the server-side, like >within stored procedures or COM/EJB. > >On the other hand, if I was working on an application with all of its >complexity within CF, I'd probably like Fusebox quite a bit. Once you move >most of that complexity from CF to other tiers, though, Fusebox doesn't do >much for you, in my opinion. > >Dave Watts, CTO, Fig Leaf Software >http://www.figleaf.com/ >voice: (202) 797-5496 >fax: (202) 797-5444 > > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a >message with 'unsubscribe' in the body to [EMAIL PROTECTED] > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message >with 'unsubscribe' in the body to [EMAIL PROTECTED] --- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 x204 Fax 1.212.545.0938 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Re: fusebox style: too much disk access?
That's the best possible case for cacheing. If everyone is acessing the same file you can bet it will be in cache and will serve out quickly. Did I understand Jeremy Allen correctly that the CF server will compile the entire page to P-Code *with any included files* and cache it. How does it track the myriad of combinations when all of the s are dynamic (inside CFIFs) and different files are included depending on the input and data? At 11:44 AM 10/20/00 -0400, Donald Sparks wrote: >Okay, I'm not concerned with cfincludes and those related issues. I am concerned with >the handling of multiple requests on the index or "fusebox" page (i.e.) a single >page. For example say I have 1,000 users on my site. If they are all accessing >index.cfm as opposed to 20 to 30 different .cfm pages. How does this affect caching >and does it produce any other problems. > >Thank you, >Don Sparks >not quite at the 32nd chamber of fusebox. > >- Original Message - >From: "Steve Nelson" <[EMAIL PROTECTED]> >To: "CF-Talk" <[EMAIL PROTECTED]> >Sent: Thursday, October 19, 2000 3:23 PM >Subject: Re: fusebox style: too much disk access? > > >> Don't be confused by what Nat is saying, a single "fuseaction" in a >> Fusebox application may only hit 5-8 files. It's really not that big a >> deal. >> >> Steve >> >> Nat Papovich wrote: >> > >> > A simple test of included files suggests that CF's internal file access >> > functions were pratically built with a cfinclude-heavy architecture in >mind. >> > Accessing dozens of files for a single page request is very quick. Out >of >> > 100 included files, you might notice a 10 ms increase than if you had >all >> > the code on the same page. Now that 10 ms performance hit gives you a >> > scalable, intelligible architecture. If you have any experience with >really >> > large sites, you know that the only safe way to scale a project is to >break >> > it into small "minute modules". >> > >> > All this is without mentioning CF's ability to cache templates >> > automatically. Accessing a file from RAM is basically instantaneous. >> > >> > If code scalability, readability, longevity, and understandability is >> > important now or will be important later, you need to adopt a structured >> > application methodology like Fusebox. >> > >> > Nat Papovich >> > ICQ 32676414 >> > "I'm for truth no matter who tells it." >> > -Malcolm X, 1965 >> > >> > -Original Message- >> > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] >> > Sent: Thursday, October 19, 2000 1:00 PM >> > To: CF-Talk >> > Subject: fusebox style: too much disk access? >> > >> > I was reading on the fusebox concept of putting minute modules into >separate >> > files and the question is: wouldn't that slow the site by having to >access >> > too many different disk files to load one page? >> > >> > Cyrill >> > > > > > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message >with 'unsubscribe' in the body to [EMAIL PROTECTED] --- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 x204 Fax 1.212.545.0938 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
Peter that was more of a theoretical guess than an actual statement but I will reenforce it. My assumptions based on how C compilers work. There is a preprocessing phase for a individual page call. Step one, preprocess any individual CF template include any files into the template do anything else (syntax checking after the inclusion, before the inclusion) there are to many things to talk about so ill just stick to including files. After "pre processing" you now have a template to be interpreted. The next phase since we all know that CF "compiles" templates to PCode is to turn that template into PCode. So one Section of my site may have 10 fuses which is really just 10 seperate Compilations (10 different file configurations) Again most of this is theory if anyone actually knows I would love to hear it, im just taking some guesses here. At this point I can only state guesses since I am not entirely certain. Dave? Allaire people? Anyone care to comment on how this works. My guess is say you have 30 different combinations to CF that is just 30 different PCode compilations not so many to leave in memory. If it parses a template and finds it has changed or has a different combination of CFINCLUDES I imagine it just compiles a newer version. This is memory intensive but is what gives lightning fast runtimes even for fusebox stuff... Its a really good question actually Peter and one I have wanted someone to comment on every time I have mentioned this. BTW I realize the actual CFENGINE is much more complex I am just grossly simplfying it for my example. If that is not how it works I dont see how Fusebox and any application using a lot of CFINCLUDES can get away with working in an effecient manner. It somehow has to be translating the pages to PCode or using some method of caching or combinations thereof. Anyways someone enlighten us :) Jeremy Allen [EMAIL PROTECTED] -Original Message- From: Peter Theobald [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 4:47 PM To: CF-Talk Subject: Re: fusebox style: too much disk access? That's the best possible case for cacheing. If everyone is acessing the same file you can bet it will be in cache and will serve out quickly. Did I understand Jeremy Allen correctly that the CF server will compile the entire page to P-Code *with any included files* and cache it. How does it track the myriad of combinations when all of the s are dynamic (inside CFIFs) and different files are included depending on the input and data? At 11:44 AM 10/20/00 -0400, Donald Sparks wrote: >Okay, I'm not concerned with cfincludes and those related issues. I am concerned with the handling of multiple requests on the index or "fusebox" page (i.e.) a single page. For example say I have 1,000 users on my site. If they are all accessing index.cfm as opposed to 20 to 30 different .cfm pages. How does this affect caching and does it produce any other problems. > >Thank you, >Don Sparks >not quite at the 32nd chamber of fusebox. > >- Original Message - >From: "Steve Nelson" <[EMAIL PROTECTED]> >To: "CF-Talk" <[EMAIL PROTECTED]> >Sent: Thursday, October 19, 2000 3:23 PM >Subject: Re: fusebox style: too much disk access? > > >> Don't be confused by what Nat is saying, a single "fuseaction" in a >> Fusebox application may only hit 5-8 files. It's really not that big a >> deal. >> >> Steve >> >> Nat Papovich wrote: >> > >> > A simple test of included files suggests that CF's internal file access >> > functions were pratically built with a cfinclude-heavy architecture in >mind. >> > Accessing dozens of files for a single page request is very quick. Out >of >> > 100 included files, you might notice a 10 ms increase than if you had >all >> > the code on the same page. Now that 10 ms performance hit gives you a >> > scalable, intelligible architecture. If you have any experience with >really >> > large sites, you know that the only safe way to scale a project is to >break >> > it into small "minute modules". >> > >> > All this is without mentioning CF's ability to cache templates >> > automatically. Accessing a file from RAM is basically instantaneous. >> > >> > If code scalability, readability, longevity, and understandability is >> > important now or will be important later, you need to adopt a structured >> > application methodology like Fusebox. >> > >> > Nat Papovich >> > ICQ 32676414 >> > "I'm for truth no matter who tells it." >> > -Malcolm X, 1965 >> > >> > ---
RE: fusebox style: too much disk access?
Actually, using FuseBox with 10 fuses you may have 10 separate configurations, but If I have 10 "actions" that are NOT mutually exclusive then I have 100 (10x10) configurations. Perhaps the server compiles to P-Code, without the included files, and there is a P-Code instruction to include a file. At 05:00 PM 10/20/00 -0400, Jeremy Allen wrote: >Peter that was more of a theoretical guess than an actual statement >but I will reenforce it. > >My assumptions based on how C compilers work. > >There is a preprocessing phase for a individual page call. > > >Step one, preprocess any individual CF template include any >files into the template do anything else (syntax checking >after the inclusion, before the inclusion) there are to >many things to talk about so ill just stick to including files. > >After "pre processing" you now have a template to be interpreted. > >The next phase since we all know that CF "compiles" templates >to PCode is to turn that template into PCode. > >So one Section of my site may have 10 fuses which is really >just 10 seperate Compilations (10 different file configurations) > >Again most of this is theory if anyone actually knows I would >love to hear it, im just taking some guesses here. > >At this point I can only state guesses since I am not entirely >certain. Dave? Allaire people? > >Anyone care to comment on how this works. > >My guess is say you have 30 different combinations to >CF that is just 30 different PCode compilations not so >many to leave in memory. > >If it parses a template and finds it has changed or >has a different combination of CFINCLUDES I imagine >it just compiles a newer version. This is memory >intensive but is what gives lightning fast runtimes >even for fusebox stuff... > >Its a really good question actually Peter and one I have >wanted someone to comment on every time I have mentioned >this. > >BTW I realize the actual CFENGINE is much more complex I am >just grossly simplfying it for my example. > >If that is not how it works I dont see how Fusebox and any >application using a lot of CFINCLUDES can get away with working >in an effecient manner. It somehow has to be translating the >pages to PCode or using some method of caching or combinations >thereof. Anyways someone enlighten us :) > > >Jeremy Allen >[EMAIL PROTECTED] > > >-Original Message- >From: Peter Theobald [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 20, 2000 4:47 PM >To: CF-Talk >Subject: Re: fusebox style: too much disk access? > > >That's the best possible case for cacheing. If everyone is acessing the same >file you can bet it will be in cache and will serve out quickly. > >Did I understand Jeremy Allen correctly that the CF server will compile the >entire page to P-Code *with any included files* and cache it. How does it >track the myriad of combinations when all of the s are dynamic >(inside CFIFs) and different files are included depending on the input and >data? > >At 11:44 AM 10/20/00 -0400, Donald Sparks wrote: >>Okay, I'm not concerned with cfincludes and those related issues. I am >concerned with the handling of multiple requests on the index or "fusebox" >page (i.e.) a single page. For example say I have 1,000 users on my site. If >they are all accessing index.cfm as opposed to 20 to 30 different .cfm >pages. How does this affect caching and does it produce any other problems. >> >>Thank you, >>Don Sparks >>not quite at the 32nd chamber of fusebox. >> >>- Original Message - >>From: "Steve Nelson" <[EMAIL PROTECTED]> >>To: "CF-Talk" <[EMAIL PROTECTED]> >>Sent: Thursday, October 19, 2000 3:23 PM >>Subject: Re: fusebox style: too much disk access? >> >> >>> Don't be confused by what Nat is saying, a single "fuseaction" in a >>> Fusebox application may only hit 5-8 files. It's really not that big a >>> deal. >>> >>> Steve >>> >>> Nat Papovich wrote: >>> > >>> > A simple test of included files suggests that CF's internal file access >>> > functions were pratically built with a cfinclude-heavy architecture in >>mind. >>> > Accessing dozens of files for a single page request is very quick. Out >>of >>> > 100 included files, you might notice a 10 ms increase than if you had >>all >>> > the code on the same page. Now that 10 ms performance hit gives you a >>> > scalable, intelligible architecture. If you have any experience with >>really >>> > large sites, you know that the o
RE: fusebox style: too much disk access?
I was afraid this would happen. I'm surprised that Sean Renet hasn't
contributed yet, though!
> What-evah, Dave. Fusebox kicks ass for the very implementation
> you mention. COMs can be called from a single file (using a new
> prefix com_filename.cfm if you want), then whenever you need
> that COM, you cfinclude that file.
Well, I could do that, but for most purposes, what would be the point?
Let's say I use a COM object many places in my application. This doesn't
mean that I'm going to use the same methods and properties of that object
each time. So, I create a file:
OK. Well, that sure buys me a lot, doesn't it? Admittedly, you might reuse
some of the methods and properties, but then again you might not. The point
of using COM, in my opinion, is that it IS an encapsulation - I simply
instantiate the object, then use it. I don't need to encapsulate the
encapsulation!
> Maybe it would help us if you made a distinction between
> application logic encapsulation and business rules
> encapsulation. If you do both within COM/EJB, then you
> practically don't even need CF for anything other than
> CFOUTPUT. If however, you want application logic in COM, but
> still want business rules in CF, then Fusebox is great. No?
>
> It seems to me that if you remove application and business
> logic from CF, then a structured application architecture
> (like Fusebox) becomes less of a necessity. What kind of
> CF architecture do you guys use in EJB/COM-heavy apps?
In my world, application logic is the whole enchilada. Business rules are a
subset of application logic; specific algorithms written to model rules and
limitations imposed by the business process. In the real world, of course,
it's often difficult to cleanly separate business rules from everything
else, but we try.
In most Fig Leaf applications, we actually don't use all that many COM or
EJB components, although we're certainly moving in that direction more and
more, it seems. However, we're still distributing application logic across
multiple tiers.
We'll often place significant amounts within stored procedures. Now,
according to Fusebox, we should then place the stored procedure calls within
separate "qry_" or "act_" files. Of course, since all the real code is in
the stored procedure, and we often call the stored procedure using CFQUERY
(as we can then cache the recordset using CFQUERY's caching attributes),
we'd have something like this:
{ call myspFoo(#mynumericparam#, '#mytextparam#') }
Again, not a lot of reuse value. In fact, at this point, using Fusebox seems
to me to be just another layer of abstraction I'd have to deal with.
That's really where I draw the line. I could use it with anything - frames,
JavaScript, WML, COM/EJB, stored procedures, etc. However, at a certain
point, it adds complexity rather than making things simpler. The reason I
like CF is that it's a comparatively simple, high-level language which is
easy to read. Given that within a well-constructed application, you're
generally going to have a relatively self-documenting structure of
directories/subdirectories and of functionality, the price for making every
last line of code so self-descriptive seems a bit high to me. There just
isn't that much CFML code to organize! The amount of organizational
structure in Fusebox seems to me to exceed the amount of algorithmic
content.
As for what kind of CF architecture we use (whether in object-tier apps or
not), we simply use a "common sense" architecture. We design the application
before building it, and we organize the CF portion of the application in a
modular subdirectory structure. We have some standards for using
frames-based interfaces, we have other standards for using JavaScript to
work with recordsets on the client, and so on.
Within our organization, we frequently move developers from one project to
another, without any major difficulties in understanding the flow of the
application.
Finally, I've never told anyone "don't use Fusebox". I've said that I don't
think it's the best choice for everything, and that I don't use it. If you
like it, go ahead and use it! But if you don't, don't use it just because
"it's what everybody uses".
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
Dave Watts Said:
"There just isn't that much CFML code to organize!"
And that about sums it up, folks. If you have an application without "that
much CFML" then you don't need any kind of organization.
However, if all your business and application logic is performed by CF and
SQL and you don't use more than those 2 tiers (CF for logic and display and
SQL for backend), then a structured application architecture (like Fusebox)
is mucho important, regardless of the minor decrease in speed for numbers of
included files.
Nat Papovich
ICQ 32676414
"I'm for truth no matter who tells it."
-Malcolm X, 1965
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 20, 2000 3:03 PM
To: CF-Talk
Cc: Nat Papovich
Subject: RE: fusebox style: too much disk access?
I was afraid this would happen. I'm surprised that Sean Renet hasn't
contributed yet, though!
> What-evah, Dave. Fusebox kicks ass for the very implementation
> you mention. COMs can be called from a single file (using a new
> prefix com_filename.cfm if you want), then whenever you need
> that COM, you cfinclude that file.
Well, I could do that, but for most purposes, what would be the point?
Let's say I use a COM object many places in my application. This doesn't
mean that I'm going to use the same methods and properties of that object
each time. So, I create a file:
OK. Well, that sure buys me a lot, doesn't it? Admittedly, you might reuse
some of the methods and properties, but then again you might not. The point
of using COM, in my opinion, is that it IS an encapsulation - I simply
instantiate the object, then use it. I don't need to encapsulate the
encapsulation!
> Maybe it would help us if you made a distinction between
> application logic encapsulation and business rules
> encapsulation. If you do both within COM/EJB, then you
> practically don't even need CF for anything other than
> CFOUTPUT. If however, you want application logic in COM, but
> still want business rules in CF, then Fusebox is great. No?
>
> It seems to me that if you remove application and business
> logic from CF, then a structured application architecture
> (like Fusebox) becomes less of a necessity. What kind of
> CF architecture do you guys use in EJB/COM-heavy apps?
In my world, application logic is the whole enchilada. Business rules are a
subset of application logic; specific algorithms written to model rules and
limitations imposed by the business process. In the real world, of course,
it's often difficult to cleanly separate business rules from everything
else, but we try.
In most Fig Leaf applications, we actually don't use all that many COM or
EJB components, although we're certainly moving in that direction more and
more, it seems. However, we're still distributing application logic across
multiple tiers.
We'll often place significant amounts within stored procedures. Now,
according to Fusebox, we should then place the stored procedure calls within
separate "qry_" or "act_" files. Of course, since all the real code is in
the stored procedure, and we often call the stored procedure using CFQUERY
(as we can then cache the recordset using CFQUERY's caching attributes),
we'd have something like this:
{ call myspFoo(#mynumericparam#, '#mytextparam#') }
Again, not a lot of reuse value. In fact, at this point, using Fusebox seems
to me to be just another layer of abstraction I'd have to deal with.
That's really where I draw the line. I could use it with anything - frames,
JavaScript, WML, COM/EJB, stored procedures, etc. However, at a certain
point, it adds complexity rather than making things simpler. The reason I
like CF is that it's a comparatively simple, high-level language which is
easy to read. Given that within a well-constructed application, you're
generally going to have a relatively self-documenting structure of
directories/subdirectories and of functionality, the price for making every
last line of code so self-descriptive seems a bit high to me. There just
isn't that much CFML code to organize! The amount of organizational
structure in Fusebox seems to me to exceed the amount of algorithmic
content.
As for what kind of CF architecture we use (whether in object-tier apps or
not), we simply use a "common sense" architecture. We design the application
before building it, and we organize the CF portion of the application in a
modular subdirectory structure. We have some standards for using
frames-based interfaces, we have other standards for using JavaScript to
work with recordsets on the client, and so on.
Within our organization, we frequently move developers from one project to
another, without any major difficulties in understanding the flow of the
app
RE: fusebox style: too much disk access?
If the code is logical, organized, and well written, it shouldn't matter if you utilize the Fusebox methodology or not, fusebox assists people with accomplishing these things. If you do it without using the fusebox methodology, that doesn't make you wrong. Any approach to programming that is not logical, organized, and well written is a pain to debug, maintain, and update, regardless of whether it is in fusebox or not. The fact that so many fuseboxers take offense to non-fuseboxers and vice versa is rather disturbing. We should strive to forward ourselves by not getting into nit picky arguments amongst ourselves about matters of style, and focus on helping each other with the problems that we all run into. -Original Message- From: Peter Theobald [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 3:33 PM To: CF-Talk Subject: RE: fusebox style: too much disk access? Since we're talking about it... I always thought that breaking up an application by "type of activity in the file" like dsp for display and qry for query didn't make sense. I want to break up my application by logical "object" like a user profile, an inventory item, etc.. At 11:19 AM 10/20/00 -0700, Nat Papovich wrote: >What-evah, Dave. Fusebox kicks ass for the very implementation you mention. >COMs can be called from a single file (using a new prefix com_filename.cfm >if you want), then whenever you need that COM, you cfinclude that file. > >Maybe it would help us if you made a distinction between application logic >encapsulation and business rules encapsulation. If you do both within >COM/EJB, then you practically don't even need CF for anything other than >CFOUTPUT. If however, you want application logic in COM, but still want >business rules in CF, then Fusebox is great. No? > >It seems to me that if you remove application and business logic from CF, >then a structured application architecture (like Fusebox) becomes less of a >necessity. What kind of CF architecture do you guys use in EJB/COM-heavy >apps? > >Nat Papovich >ICQ 32676414 >"I'm for truth no matter who tells it." >-Malcolm X, 1965 > > >-Original Message- >From: Dave Watts [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 20, 2000 10:12 AM >To: CF-Talk >Cc: '[EMAIL PROTECTED]' >Subject: RE: fusebox style: too much disk access? > > >> > I'm not a Fusebox fan, by any measure, >> >> Why not? What would need to be changed to make you a fan? > >I'd have to be working on applications where the complex logic is stored in >CF, instead of in other application tiers. I don't want to fuel another "Is >Fusebox good or bad" thread, but I don't think it fits well with the type of >applications that we focus on here at Fig Leaf, which typically have lots of >client-side complexity, like frames, JavaScript, Flash, etc. and have lots >of application logic within other application tiers on the server-side, like >within stored procedures or COM/EJB. > >On the other hand, if I was working on an application with all of its >complexity within CF, I'd probably like Fusebox quite a bit. Once you move >most of that complexity from CF to other tiers, though, Fusebox doesn't do >much for you, in my opinion. > >Dave Watts, CTO, Fig Leaf Software >http://www.figleaf.com/ >voice: (202) 797-5496 >fax: (202) 797-5444 >--- - > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a >message with 'unsubscribe' in the body to [EMAIL PROTECTED] >--- - >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] --- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 x204 Fax 1.212.545.0938 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
well stated >From: "Jones, Matt" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: CF-Talk <[EMAIL PROTECTED]> >Subject: RE: fusebox style: too much disk access? >Date: Fri, 20 Oct 2000 17:41:59 -0500 > >If the code is logical, organized, and well written, it shouldn't matter if >you utilize the Fusebox methodology or not, fusebox assists people with >accomplishing these things. If you do it without using the fusebox >methodology, that doesn't make you wrong. Any approach to programming that >is not logical, organized, and well written is a pain to debug, maintain, >and update, regardless of whether it is in fusebox or not. The fact that >so >many fuseboxers take offense to non-fuseboxers and vice versa is rather >disturbing. We should strive to forward ourselves by not getting into nit >picky arguments amongst ourselves about matters of style, and focus on >helping each other with the problems that we all run into. > >-Original Message- >From: Peter Theobald [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 20, 2000 3:33 PM >To: CF-Talk >Subject: RE: fusebox style: too much disk access? > > >Since we're talking about it... I always thought that breaking up an >application by "type of activity in the file" like dsp for display and qry >for query didn't make sense. I want to break up my application by logical >"object" like a user profile, an inventory item, etc.. > > >At 11:19 AM 10/20/00 -0700, Nat Papovich wrote: > >What-evah, Dave. Fusebox kicks ass for the very implementation you >mention. > >COMs can be called from a single file (using a new prefix >com_filename.cfm > >if you want), then whenever you need that COM, you cfinclude that file. > > > >Maybe it would help us if you made a distinction between application >logic > >encapsulation and business rules encapsulation. If you do both within > >COM/EJB, then you practically don't even need CF for anything other than > >CFOUTPUT. If however, you want application logic in COM, but still want > >business rules in CF, then Fusebox is great. No? > > > >It seems to me that if you remove application and business logic from CF, > >then a structured application architecture (like Fusebox) becomes less of >a > >necessity. What kind of CF architecture do you guys use in EJB/COM-heavy > >apps? > > > >Nat Papovich > >ICQ 32676414 > >"I'm for truth no matter who tells it." > >-Malcolm X, 1965 > > > > > >-Original Message- > >From: Dave Watts [mailto:[EMAIL PROTECTED]] > >Sent: Friday, October 20, 2000 10:12 AM > >To: CF-Talk > >Cc: '[EMAIL PROTECTED]' > >Subject: RE: fusebox style: too much disk access? > > > > > >> > I'm not a Fusebox fan, by any measure, > >> > >> Why not? What would need to be changed to make you a fan? > > > >I'd have to be working on applications where the complex logic is stored >in > >CF, instead of in other application tiers. I don't want to fuel another >"Is > >Fusebox good or bad" thread, but I don't think it fits well with the type >of > >applications that we focus on here at Fig Leaf, which typically have lots >of > >client-side complexity, like frames, JavaScript, Flash, etc. and have >lots > >of application logic within other application tiers on the server-side, >like > >within stored procedures or COM/EJB. > > > >On the other hand, if I was working on an application with all of its > >complexity within CF, I'd probably like Fusebox quite a bit. Once you >move > >most of that complexity from CF to other tiers, though, Fusebox doesn't >do > >much for you, in my opinion. > > > >Dave Watts, CTO, Fig Leaf Software > >http://www.figleaf.com/ > >voice: (202) 797-5496 > >fax: (202) 797-5444 > >--- >- > > > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send >a > >message with 'unsubscribe' in the body to >[EMAIL PROTECTED] > >--- >- > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send >a >message with 'unsubscribe' in the body to >[EMAIL PROTECTED] > > > >--
RE: fusebox style: too much disk access?
I've got a fusebox tattoo, so nah! :^) Kidding, Brad -Original Message- From: Jones, Matt [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 6:42 PM To: CF-Talk Subject: RE: fusebox style: too much disk access? If the code is logical, organized, and well written, it shouldn't matter if you utilize the Fusebox methodology or not, fusebox assists people with accomplishing these things. If you do it without using the fusebox methodology, that doesn't make you wrong. Any approach to programming that is not logical, organized, and well written is a pain to debug, maintain, and update, regardless of whether it is in fusebox or not. The fact that so many fuseboxers take offense to non-fuseboxers and vice versa is rather disturbing. We should strive to forward ourselves by not getting into nit picky arguments amongst ourselves about matters of style, and focus on helping each other with the problems that we all run into. -Original Message- From: Peter Theobald [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 3:33 PM To: CF-Talk Subject: RE: fusebox style: too much disk access? Since we're talking about it... I always thought that breaking up an application by "type of activity in the file" like dsp for display and qry for query didn't make sense. I want to break up my application by logical "object" like a user profile, an inventory item, etc.. At 11:19 AM 10/20/00 -0700, Nat Papovich wrote: >What-evah, Dave. Fusebox kicks ass for the very implementation you mention. >COMs can be called from a single file (using a new prefix com_filename.cfm >if you want), then whenever you need that COM, you cfinclude that file. > >Maybe it would help us if you made a distinction between application logic >encapsulation and business rules encapsulation. If you do both within >COM/EJB, then you practically don't even need CF for anything other than >CFOUTPUT. If however, you want application logic in COM, but still want >business rules in CF, then Fusebox is great. No? > >It seems to me that if you remove application and business logic from CF, >then a structured application architecture (like Fusebox) becomes less of a >necessity. What kind of CF architecture do you guys use in EJB/COM-heavy >apps? > >Nat Papovich >ICQ 32676414 >"I'm for truth no matter who tells it." >-Malcolm X, 1965 > > >-Original Message- >From: Dave Watts [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 20, 2000 10:12 AM >To: CF-Talk >Cc: '[EMAIL PROTECTED]' >Subject: RE: fusebox style: too much disk access? > > >> > I'm not a Fusebox fan, by any measure, >> >> Why not? What would need to be changed to make you a fan? > >I'd have to be working on applications where the complex logic is stored in >CF, instead of in other application tiers. I don't want to fuel another "Is >Fusebox good or bad" thread, but I don't think it fits well with the type of >applications that we focus on here at Fig Leaf, which typically have lots of >client-side complexity, like frames, JavaScript, Flash, etc. and have lots >of application logic within other application tiers on the server-side, like >within stored procedures or COM/EJB. > >On the other hand, if I was working on an application with all of its >complexity within CF, I'd probably like Fusebox quite a bit. Once you move >most of that complexity from CF to other tiers, though, Fusebox doesn't do >much for you, in my opinion. > >Dave Watts, CTO, Fig Leaf Software >http://www.figleaf.com/ >voice: (202) 797-5496 >fax: (202) 797-5444 >--- - > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a >message with 'unsubscribe' in the body to [EMAIL PROTECTED] >--- - >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] --- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 x204 Fax 1.212.545.0938 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe'
RE: fusebox style: too much disk access?
I'm all for structured architectures, first and foremost. There is no way that someone like Dave Watts is building poorly architected applications. The main reason why Fuseboxers are so adamant is because of the schtuff that Hal Helms (aka Superman) is working on right now including nesting Fuseboxes, remote and disparate developers, separating architecture from coding, etc. That's why an architecture that many developers are famililar with and use is nice. Not the be-all-end-all, but nice. Hey it's just a stupid computer anyway. What does it REALLY matter? Nat Papovich ICQ 32676414 "I'm for truth no matter who tells it." -Malcolm X, 1965 -Original Message- From: Jones, Matt [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 3:42 PM To: CF-Talk Subject: RE: fusebox style: too much disk access? If the code is logical, organized, and well written, it shouldn't matter if you utilize the Fusebox methodology or not, fusebox assists people with accomplishing these things. If you do it without using the fusebox methodology, that doesn't make you wrong. Any approach to programming that is not logical, organized, and well written is a pain to debug, maintain, and update, regardless of whether it is in fusebox or not. The fact that so many fuseboxers take offense to non-fuseboxers and vice versa is rather disturbing. We should strive to forward ourselves by not getting into nit picky arguments amongst ourselves about matters of style, and focus on helping each other with the problems that we all run into. -Original Message- From: Peter Theobald [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 3:33 PM To: CF-Talk Subject: RE: fusebox style: too much disk access? Since we're talking about it... I always thought that breaking up an application by "type of activity in the file" like dsp for display and qry for query didn't make sense. I want to break up my application by logical "object" like a user profile, an inventory item, etc.. At 11:19 AM 10/20/00 -0700, Nat Papovich wrote: >What-evah, Dave. Fusebox kicks ass for the very implementation you mention. >COMs can be called from a single file (using a new prefix com_filename.cfm >if you want), then whenever you need that COM, you cfinclude that file. > >Maybe it would help us if you made a distinction between application logic >encapsulation and business rules encapsulation. If you do both within >COM/EJB, then you practically don't even need CF for anything other than >CFOUTPUT. If however, you want application logic in COM, but still want >business rules in CF, then Fusebox is great. No? > >It seems to me that if you remove application and business logic from CF, >then a structured application architecture (like Fusebox) becomes less of a >necessity. What kind of CF architecture do you guys use in EJB/COM-heavy >apps? > >Nat Papovich >ICQ 32676414 >"I'm for truth no matter who tells it." >-Malcolm X, 1965 > > >-Original Message----- >From: Dave Watts [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 20, 2000 10:12 AM >To: CF-Talk >Cc: '[EMAIL PROTECTED]' >Subject: RE: fusebox style: too much disk access? > > >> > I'm not a Fusebox fan, by any measure, >> >> Why not? What would need to be changed to make you a fan? > >I'd have to be working on applications where the complex logic is stored in >CF, instead of in other application tiers. I don't want to fuel another "Is >Fusebox good or bad" thread, but I don't think it fits well with the type of >applications that we focus on here at Fig Leaf, which typically have lots of >client-side complexity, like frames, JavaScript, Flash, etc. and have lots >of application logic within other application tiers on the server-side, like >within stored procedures or COM/EJB. > >On the other hand, if I was working on an application with all of its >complexity within CF, I'd probably like Fusebox quite a bit. Once you move >most of that complexity from CF to other tiers, though, Fusebox doesn't do >much for you, in my opinion. > >Dave Watts, CTO, Fig Leaf Software >http://www.figleaf.com/ >voice: (202) 797-5496 >fax: (202) 797-5444 >--- - > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a >message with 'unsubscribe' in the body to [EMAIL PROTECTED] >--- - >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >Unsubscribe: http://www.house
RE: fusebox style: too much disk access?
Yeah, but hey isn't it cool when you explain your methodology to a client and bad mouth all us anal-retentive Fuseboxers and somehow look like you totally know what you're doing? (I'm totally kidding, of course.) I find that no matter what your methodology is, if someone else can easily understand and adopt it, then it is truely valuable because that provides added value to the service that we all provide. Imagine how many times you've picked up an application after someone else and wished you could understand their logic. :) TGIF ---mark -- Mark Warrick Phone: (714) 547-5386 Efax.com Fax: (801) 730-7289 Personal Email: [EMAIL PROTECTED] Personal URL: http://www.warrick.net Business Email: [EMAIL PROTECTED] Business URL: http://www.fusioneers.com ICQ: 346566 -- > -Original Message- > From: Jones, Matt [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 20, 2000 3:42 PM > To: CF-Talk > Subject: RE: fusebox style: too much disk access? > > > If the code is logical, organized, and well written, it shouldn't > matter if > you utilize the Fusebox methodology or not, fusebox assists people with > accomplishing these things. If you do it without using the fusebox > methodology, that doesn't make you wrong. Any approach to > programming that > is not logical, organized, and well written is a pain to debug, maintain, > and update, regardless of whether it is in fusebox or not. The > fact that so > many fuseboxers take offense to non-fuseboxers and vice versa is rather > disturbing. We should strive to forward ourselves by not getting into nit > picky arguments amongst ourselves about matters of style, and focus on > helping each other with the problems that we all run into. > > -Original Message- > From: Peter Theobald [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 20, 2000 3:33 PM > To: CF-Talk > Subject: RE: fusebox style: too much disk access? > > > Since we're talking about it... I always thought that breaking up an > application by "type of activity in the file" like dsp for display and qry > for query didn't make sense. I want to break up my application by logical > "object" like a user profile, an inventory item, etc.. > > > At 11:19 AM 10/20/00 -0700, Nat Papovich wrote: > >What-evah, Dave. Fusebox kicks ass for the very implementation > you mention. > >COMs can be called from a single file (using a new prefix > com_filename.cfm > >if you want), then whenever you need that COM, you cfinclude that file. > > > >Maybe it would help us if you made a distinction between > application logic > >encapsulation and business rules encapsulation. If you do both within > >COM/EJB, then you practically don't even need CF for anything other than > >CFOUTPUT. If however, you want application logic in COM, but still want > >business rules in CF, then Fusebox is great. No? > > > >It seems to me that if you remove application and business logic from CF, > >then a structured application architecture (like Fusebox) > becomes less of a > >necessity. What kind of CF architecture do you guys use in EJB/COM-heavy > >apps? > > > >Nat Papovich > >ICQ 32676414 > >"I'm for truth no matter who tells it." > >-Malcolm X, 1965 > > > > > >-Original Message- > >From: Dave Watts [mailto:[EMAIL PROTECTED]] > >Sent: Friday, October 20, 2000 10:12 AM > >To: CF-Talk > >Cc: '[EMAIL PROTECTED]' > >Subject: RE: fusebox style: too much disk access? > > > > > >> > I'm not a Fusebox fan, by any measure, > >> > >> Why not? What would need to be changed to make you a fan? > > > >I'd have to be working on applications where the complex logic > is stored in > >CF, instead of in other application tiers. I don't want to fuel > another "Is > >Fusebox good or bad" thread, but I don't think it fits well with the type > of > >applications that we focus on here at Fig Leaf, which typically have lots > of > >client-side complexity, like frames, JavaScript, Flash, etc. and > have lots > >of application logic within other application tiers on the server-side, > like > >within stored procedures or COM/EJB. > > > >On the other hand, if I was working on an application with all of its > >complexity within CF, I'd probably like Fusebox quite a bit. > Once you move > >most
RE: fusebox style: too much disk access?
Actually, I find some of the "nit picking" productive, because I'd like to know what is the value some people find in some of the Fusebox conventions that I don't find valuable. Perhaps I don't realize a situation where some convention comes in really handy. But we digress too much... off to the FuseBox list for more of this... At 05:41 PM 10/20/00 -0500, Jones, Matt wrote: >If the code is logical, organized, and well written, it shouldn't matter if >you utilize the Fusebox methodology or not, fusebox assists people with >accomplishing these things. If you do it without using the fusebox >methodology, that doesn't make you wrong. Any approach to programming that >is not logical, organized, and well written is a pain to debug, maintain, >and update, regardless of whether it is in fusebox or not. The fact that so >many fuseboxers take offense to non-fuseboxers and vice versa is rather >disturbing. We should strive to forward ourselves by not getting into nit >picky arguments amongst ourselves about matters of style, and focus on >helping each other with the problems that we all run into. > >-Original Message- >From: Peter Theobald [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 20, 2000 3:33 PM >To: CF-Talk >Subject: RE: fusebox style: too much disk access? > > >Since we're talking about it... I always thought that breaking up an >application by "type of activity in the file" like dsp for display and qry >for query didn't make sense. I want to break up my application by logical >"object" like a user profile, an inventory item, etc.. > > >At 11:19 AM 10/20/00 -0700, Nat Papovich wrote: >>What-evah, Dave. Fusebox kicks ass for the very implementation you mention. >>COMs can be called from a single file (using a new prefix com_filename.cfm >>if you want), then whenever you need that COM, you cfinclude that file. >> >>Maybe it would help us if you made a distinction between application logic >>encapsulation and business rules encapsulation. If you do both within >>COM/EJB, then you practically don't even need CF for anything other than >>CFOUTPUT. If however, you want application logic in COM, but still want >>business rules in CF, then Fusebox is great. No? >> >>It seems to me that if you remove application and business logic from CF, >>then a structured application architecture (like Fusebox) becomes less of a >>necessity. What kind of CF architecture do you guys use in EJB/COM-heavy >>apps? >> >>Nat Papovich >>ICQ 32676414 >>"I'm for truth no matter who tells it." >>-Malcolm X, 1965 >> >> >>-Original Message- >>From: Dave Watts [mailto:[EMAIL PROTECTED]] >>Sent: Friday, October 20, 2000 10:12 AM >>To: CF-Talk >>Cc: '[EMAIL PROTECTED]' >>Subject: RE: fusebox style: too much disk access? >> >> >>> > I'm not a Fusebox fan, by any measure, >>> >>> Why not? What would need to be changed to make you a fan? >> >>I'd have to be working on applications where the complex logic is stored in >>CF, instead of in other application tiers. I don't want to fuel another "Is >>Fusebox good or bad" thread, but I don't think it fits well with the type >of >>applications that we focus on here at Fig Leaf, which typically have lots >of >>client-side complexity, like frames, JavaScript, Flash, etc. and have lots >>of application logic within other application tiers on the server-side, >like >>within stored procedures or COM/EJB. >> >>On the other hand, if I was working on an application with all of its >>complexity within CF, I'd probably like Fusebox quite a bit. Once you move >>most of that complexity from CF to other tiers, though, Fusebox doesn't do >>much for you, in my opinion. >> >>Dave Watts, CTO, Fig Leaf Software >>http://www.figleaf.com/ >>voice: (202) 797-5496 >>fax: (202) 797-5444 >>--- >- >> >>Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >>Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a >>message with 'unsubscribe' in the body to >[EMAIL PROTECTED] >>--- >- >>Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ >>Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a >m
RE: fusebox style: too much disk access?
Not these days, everything on the computers usually are cached. So it would be no surprise to know that files have always been cached from Windows 95/98/ME/2000. So in reality because these files are heavily used the files would be cached and would be accessed quicker the second/third time. But it is a very small issue to the server. regards Andrew Scott Senior Cold Fusion Application Developer -Original Message- From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] Sent: 20 October 2000 07:00 To: CF-Talk Subject: fusebox style: too much disk access? I was reading on the fusebox concept of putting minute modules into separate files and the question is: wouldn't that slow the site by having to access too many different disk files to load one page? Cyrill Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Re: fusebox style: too much disk access?
Fusebox does break up your application by object. It does this first, in Fusebox that's known as a "circuit application". Fusebox tries to have friendly names than in OO programming, this is so it can be more easily described to a non technical person. Here's the breakdown of a Fusebox app: 1) Home application - this is your entire site 2) Circuit Application - this is a section of your home (or one of the objects). Basically a circuit is a directory of .cfm files. so you might have a "/products" or "/users" or "/surveys". or even sub-circuits like: "/users/addresses" 3) Fuseaction - This is one of the things a circuit can do. In Object oriented programming this is known as a "method". 4) Fuse - This is one of the various files: dsp_file.cfm, qry_file.cfm, act_file.cfm, url_file.cfm, or even: com_file.cfm, ejb_file.cfm, JS_file.cfm. Fusebox suggestions files but if they don't work for you, come up with new ones, but be sure to tell everyone so others can benefit. Steve Peter Theobald wrote: > > Since we're talking about it... I always thought that breaking up an application by >"type of activity in the file" like dsp for display and qry for query didn't make >sense. I want to break up my application by logical "object" like a user profile, an >inventory item, etc.. > > At 11:19 AM 10/20/00 -0700, Nat Papovich wrote: > >What-evah, Dave. Fusebox kicks ass for the very implementation you mention. > >COMs can be called from a single file (using a new prefix com_filename.cfm > >if you want), then whenever you need that COM, you cfinclude that file. > > > >Maybe it would help us if you made a distinction between application logic > >encapsulation and business rules encapsulation. If you do both within > >COM/EJB, then you practically don't even need CF for anything other than > >CFOUTPUT. If however, you want application logic in COM, but still want > >business rules in CF, then Fusebox is great. No? > > > >It seems to me that if you remove application and business logic from CF, > >then a structured application architecture (like Fusebox) becomes less of a > >necessity. What kind of CF architecture do you guys use in EJB/COM-heavy > >apps? > > > >Nat Papovich > >ICQ 32676414 > >"I'm for truth no matter who tells it." > >-Malcolm X, 1965 > > > > > >-Original Message- > >From: Dave Watts [mailto:[EMAIL PROTECTED]] > >Sent: Friday, October 20, 2000 10:12 AM > >To: CF-Talk > >Cc: '[EMAIL PROTECTED]' > >Subject: RE: fusebox style: too much disk access? > > > > > >> > I'm not a Fusebox fan, by any measure, > >> > >> Why not? What would need to be changed to make you a fan? > > > >I'd have to be working on applications where the complex logic is stored in > >CF, instead of in other application tiers. I don't want to fuel another "Is > >Fusebox good or bad" thread, but I don't think it fits well with the type of > >applications that we focus on here at Fig Leaf, which typically have lots of > >client-side complexity, like frames, JavaScript, Flash, etc. and have lots > >of application logic within other application tiers on the server-side, like > >within stored procedures or COM/EJB. > > > >On the other hand, if I was working on an application with all of its > >complexity within CF, I'd probably like Fusebox quite a bit. Once you move > >most of that complexity from CF to other tiers, though, Fusebox doesn't do > >much for you, in my opinion. > > > >Dave Watts, CTO, Fig Leaf Software > >http://www.figleaf.com/ > >voice: (202) 797-5496 > >fax: (202) 797-5444 > > > > > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a > >message with 'unsubscribe' in the body to [EMAIL PROTECTED] > >> > >Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message >with 'unsubscribe' in the body to [EMAIL PROTECTED] > > --- > Peter Theobald, Chief Technology Officer > LiquidStreaming http://www.liquidstreaming.com > [EMAIL PROTECTED] > Phone 1.212.545.1232 x204 Fax 1.212.
Re: fusebox style: too much disk access?
>
>
>
>
> OK. Well, that sure buys me a lot, doesn't it? Admittedly, you might reuse
> some of the methods and properties, but then again you might not. The point
> of using COM, in my opinion, is that it IS an encapsulation - I simply
> instantiate the object, then use it. I don't need to encapsulate the
> encapsulation!
>
You're totally right, it doesn't need it's own file. What if you put
the call right in your index.cfm file? Maybe that's
something Fusebox is missing. Actually, it does make perfect sense to
put it in the index file because a cfobject call is essentially like
making a call except it's to a different platform.
i love it! SEE! if you had just brought this up a long time ago! haha
> We'll often place significant amounts within stored procedures. Now,
> according to Fusebox, we should then place the stored procedure calls within
> separate "qry_" or "act_" files. Of course, since all the real code is in
> the stored procedure, and we often call the stored procedure using CFQUERY
> (as we can then cache the recordset using CFQUERY's caching attributes),
> we'd have something like this:
>
>
> cachedwithin="#CreateTimeSpan(0,1,0,0)#">
> { call myspFoo(#mynumericparam#, '#mytextparam#') }
>
>
>
> Again, not a lot of reuse value. In fact, at this point, using Fusebox seems
> to me to be just another layer of abstraction I'd have to deal with.
>
ok here's why you still 'may' want to do this (you don't have to).
It's not about reusing the query file, it's about reusing the display
file.
If you separate the call named "foo" from the display code
() you can reuse that display code with a
different query that has the same name. For example:
> There just isn't that much CFML code to organize! The amount of organizational
> structure in Fusebox seems to me to exceed the amount of algorithmic
> content.
>
sure, that makes sense. If you only have a couple lines of CFML, there
really is no need for an architecture. How many .cfm files do your
normal applications have? If there are more than 50, Fusebox is will
make a difference, if there are more than 200, LOOK OUT! Fusebox kicks
ass!
> Finally, I've never told anyone "don't use Fusebox". I've said that I don't
> think it's the best choice for everything, and that I don't use it. If you
> like it, go ahead and use it! But if you don't, don't use it just because
> "it's what everybody uses".
Of course you shouldn't use it because it's what everybody uses, but if
so many people think it makes sense, it shouldn't be ignored.
Fusebox will only work in every application if every developer
contributes to it. From this conversation you have just contributed
something no one hadn't thought of before. I'm going to go bring up
this topic of adding to the index.cfm file. Thanks baby.
Steve
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
> > Did I understand Jeremy Allen correctly that the CF server > > will compile the entire page to P-Code *with any included > > files* and cache it. How does it track the myriad of > > combinations when all of the s are dynamic > > (inside CFIFs) and different files are included depending > > on the input and data? > > Peter that was more of a theoretical guess than an actual > statement but I will reenforce it. > > My assumptions based on how C compilers work. > > There is a preprocessing phase for a individual page call. > > Step one, preprocess any individual CF template include any > files into the template do anything else (syntax checking > after the inclusion, before the inclusion) there are to > many things to talk about so ill just stick to including files. > > After "pre processing" you now have a template to be interpreted. > > The next phase since we all know that CF "compiles" templates > to PCode is to turn that template into PCode. > > So one Section of my site may have 10 fuses which is really > just 10 seperate Compilations (10 different file configurations) > > Again most of this is theory if anyone actually knows I would > love to hear it, im just taking some guesses here. > > At this point I can only state guesses since I am not entirely > certain. Dave? Allaire people? Based on the background info I was given at the instructor training for the CF Performance Tuning class, CF doesn't work the same way that a C compiler might, but rather each individual .cfm file is cached individually. Using CFINCLUDEs provides the illusion that the entire body of request code is being executed as "one big file", includes and all, but it apparently doesn't really work that way. Unfortunately, this is based on a relatively vague discussion with some of the Allaire guys, so I can't state this with absolute certainty. This is one of the problems, of course, with CF - there are too many low-level mysteries on how things really work. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access?
Here, for your entertainment, are more anti-fusebox ramblings: > it's not really a question of it's good or bad, it's a > question of what is it missing? I've seen a ton of Fusebox > code with everything you've mentioned below. I'd argue that it's not a question of good or bad, but rather what's it best suited for? I think that Fusebox is a perfectly good methodology if: 1. your application's complexity is centralized within CF, and 2. one of your primary concerns is using standalone applications as modules within other applications For the kinds of applications we build, that's not our concern. We find that, for our applications, a simple directory structure is suitable for file organization, and that we're better off moving most of the complexity out of CF into something else. If we were building certain types of applications, we might use Fusebox. But we're not, and we think that, for the applications we build, Fusebox adds more complexity rather than making things easier. > It ROCKS for Frames, here is a presentation on it: > http://www.fusebox.org/Files/presentations/FuseboxandFrames.ppt I went ahead and read this. It didn't do too much for me. Although, I'll be the first to admit that very few Powerpoint presentations stand alone well - they tend to require a speaker to "fill in the blanks". Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: fusebox style: too much disk access? (back on track)
Back to the original topic of disk access... During a recent build to a production server, a friend of mine "accidentally" deleted the webroot on the live server. Because of the techincal logistics, getting a new copy on the server takes quite some time. In the meantime, the site kept plugging along, with CF serving pages from the trusted cache. Although I can't recommend that you pull out your hard drive on a production server, it will work, serving up templates from the RAM cache. Images might break though... NAT Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
Ben Forta I call on thee... was(RE: fusebox style: too much disk access?)
Mr. Forta, In other words, does the caching sytem that CF uses perform a cache per fusebox or a cache for each fuseaction? Thank you, and greatly in your debt. Don Sparks --Original Message-- From: "Jeremy Allen" <[EMAIL PROTECTED]> To: CF-Talk <[EMAIL PROTECTED]> Sent: October 20, 2000 9:00:47 PM GMT Subject: RE: fusebox style: too much disk access? Peter that was more of a theoretical guess than an actual statement but I will reenforce it. My assumptions based on how C compilers work. There is a preprocessing phase for a individual page call. Step one, preprocess any individual CF template include any files into the template do anything else (syntax checking after the inclusion, before the inclusion) there are to many things to talk about so ill just stick to including files. After "pre processing" you now have a template to be interpreted. The next phase since we all know that CF "compiles" templates to PCode is to turn that template into PCode. So one Section of my site may have 10 fuses which is really just 10 seperate Compilations (10 different file configurations) Again most of this is theory if anyone actually knows I would love to hear it, im just taking some guesses here. At this point I can only state guesses since I am not entirely certain. Dave? Allaire people? Anyone care to comment on how this works. My guess is say you have 30 different combinations to CF that is just 30 different PCode compilations not so many to leave in memory. If it parses a template and finds it has changed or has a different combination of CFINCLUDES I imagine it just compiles a newer version. This is memory intensive but is what gives lightning fast runtimes even for fusebox stuff... Its a really good question actually Peter and one I have wanted someone to comment on every time I have mentioned this. BTW I realize the actual CFENGINE is much more complex I am just grossly simplfying it for my example. If that is not how it works I dont see how Fusebox and any application using a lot of CFINCLUDES can get away with working in an effecient manner. It somehow has to be translating the pages to PCode or using some method of caching or combinations thereof. Anyways someone enlighten us :) Jeremy Allen [EMAIL PROTECTED] -Original Message- From: Peter Theobald [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 4:47 PM To: CF-Talk Subject: Re: fusebox style: too much disk access? That's the best possible case for cacheing. If everyone is acessing the same file you can bet it will be in cache and will serve out quickly. Did I understand Jeremy Allen correctly that the CF server will compile the entire page to P-Code *with any included files* and cache it. How does it track the myriad of combinations when all of the s are dynamic (inside CFIFs) and different files are included depending on the input and data? At 11:44 AM 10/20/00 -0400, Donald Sparks wrote: >Okay, I'm not concerned with cfincludes and those related issues. I am concerned with the handling of multiple requests on the index or "fusebox" page (i.e.) a single page. For example say I have 1,000 users on my site. If they are all accessing index.cfm as opposed to 20 to 30 different .cfm pages. How does this affect caching and does it produce any other problems. > >Thank you, >Don Sparks >not quite at the 32nd chamber of fusebox. > >- Original Message - >From: "Steve Nelson" <[EMAIL PROTECTED]> >To: "CF-Talk" <[EMAIL PROTECTED]> >Sent: Thursday, October 19, 2000 3:23 PM >Subject: Re: fusebox style: too much disk access? > > >> Don't be confused by what Nat is saying, a single "fuseaction" in a >> Fusebox application may only hit 5-8 files. It's really not that big a >> deal. >> >> Steve >> >> Nat Papovich wrote: >> > >> > A simple test of included files suggests that CF's internal file access >> > functions were pratically built with a cfinclude-heavy architecture in >mind. >> > Accessing dozens of files for a single page request is very quick. Out >of >> > 100 included files, you might notice a 10 ms increase than if you had >all >> > the code on the same page. Now that 10 ms performance hit gives you a >> > scalable, intelligible architecture. If you have any experience with >really >> > large sites, you know that the only safe way to scale a project is to >break >> > it into small "minute modules". >> > >> > All this is without mentioning CF's ability to cache templates >> > automatically. Accessing a file from RAM is basically instantaneous. >> > >> > If code scalability, readability, longevity, and understandability is >> > important no
RE: Ben Forta I call on thee... was(RE: fusebox style: too much disk access?)
Don, The best person to answer your question is a person from allaire, and I hope someone from allaire does answer this question, because I know a lot of people are curious as to how the CFML Engine goes about processing a request. A white paper, would be very useful. For those of us who don't work at Allaire the best we can do is speculate. To help answer the original question on this post "fusebox, too much disk access" please take a look at this article, http://www.cfdev.com/resources/discussion/messages.cfm?id=12 It explains how trusted cache numbs the disk access problem. __ Pete Freitag ([EMAIL PROTECTED]) CFDEV.COM / NETDesign Inc. ColdFusion Developer Resources http://www.cfdev.com/ -Original Message- From: Donald Sparks [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 6:03 PM To: CF-Talk Subject: Ben Forta I call on thee... was(RE: fusebox style: too much disk access?) Mr. Forta, In other words, does the caching sytem that CF uses perform a cache per fusebox or a cache for each fuseaction? Thank you, and greatly in your debt. Don Sparks --Original Message-- From: "Jeremy Allen" <[EMAIL PROTECTED]> To: CF-Talk <[EMAIL PROTECTED]> Sent: October 20, 2000 9:00:47 PM GMT Subject: RE: fusebox style: too much disk access? Peter that was more of a theoretical guess than an actual statement but I will reenforce it. My assumptions based on how C compilers work. There is a preprocessing phase for a individual page call. Step one, preprocess any individual CF template include any files into the template do anything else (syntax checking after the inclusion, before the inclusion) there are to many things to talk about so ill just stick to including files. After "pre processing" you now have a template to be interpreted. The next phase since we all know that CF "compiles" templates to PCode is to turn that template into PCode. So one Section of my site may have 10 fuses which is really just 10 seperate Compilations (10 different file configurations) Again most of this is theory if anyone actually knows I would love to hear it, im just taking some guesses here. At this point I can only state guesses since I am not entirely certain. Dave? Allaire people? Anyone care to comment on how this works. My guess is say you have 30 different combinations to CF that is just 30 different PCode compilations not so many to leave in memory. If it parses a template and finds it has changed or has a different combination of CFINCLUDES I imagine it just compiles a newer version. This is memory intensive but is what gives lightning fast runtimes even for fusebox stuff... Its a really good question actually Peter and one I have wanted someone to comment on every time I have mentioned this. BTW I realize the actual CFENGINE is much more complex I am just grossly simplfying it for my example. If that is not how it works I dont see how Fusebox and any application using a lot of CFINCLUDES can get away with working in an effecient manner. It somehow has to be translating the pages to PCode or using some method of caching or combinations thereof. Anyways someone enlighten us :) Jeremy Allen [EMAIL PROTECTED] -Original Message- From: Peter Theobald [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 4:47 PM To: CF-Talk Subject: Re: fusebox style: too much disk access? That's the best possible case for cacheing. If everyone is acessing the same file you can bet it will be in cache and will serve out quickly. Did I understand Jeremy Allen correctly that the CF server will compile the entire page to P-Code *with any included files* and cache it. How does it track the myriad of combinations when all of the s are dynamic (inside CFIFs) and different files are included depending on the input and data? At 11:44 AM 10/20/00 -0400, Donald Sparks wrote: >Okay, I'm not concerned with cfincludes and those related issues. I am concerned with the handling of multiple requests on the index or "fusebox" page (i.e.) a single page. For example say I have 1,000 users on my site. If they are all accessing index.cfm as opposed to 20 to 30 different .cfm pages. How does this affect caching and does it produce any other problems. > >Thank you, >Don Sparks >not quite at the 32nd chamber of fusebox. > >- Original Message - >From: "Steve Nelson" <[EMAIL PROTECTED]> >To: "CF-Talk" <[EMAIL PROTECTED]> >Sent: Thursday, October 19, 2000 3:23 PM >Subject: Re: fusebox style: too much disk access? > > >> Don't be confused by what Nat is saying, a single "fuseaction" in a >> Fusebox application may only hit 5-8 files. It's really not that big a >> deal. >> >> Steve >> >> Nat Papovich wrote: >> > >> > A simp
