Re: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts.
that you post (e.g.., "If you can afford SQL Server, you can afford its own box"). Can you even believe that I am still harping on this? In all honesty - today. This morning. I was reviewing a Fusebox application, to fix some problems within that application. I'm familiar with the basic tenets of Fusebox, if for no other reason than I run into it a decent amount in my line of work I meant the ongoing documentation and implementation, not a fusebox app. A fusebox app from last year would have those display header and footer templates I disdain and a bunch of other stuff that has been improved technique-wise. one group is just more honest than the other. You client is only as honest as your attorney makes them :-P What I would take issue with is the idea that Fusebox is especially well-suited to n-tier applications, or especially well-suited to complex client interfaces. That's simply not the focus of Fusebox. Again, this isn't a criticism of Fusebox - I'm not saying Fusebox is "bad". What I am saying is that it's not necessarily the best approach for everything, and that using Fusebox isn't going to be a panacea for developing complex web applications. Actually, its n-tier capabilities is one reason I use it. You are basically just plugging applications and their subapplications into each other. Admittedly, the above example could benefit from a better naming scheme in either case. Nevertheless, Fusebox in this case just provides an extra level of abstraction, which doesn't benefit me. No, you would still have to look at your frameset and then look at the pages it calls so where is the abstraction?. The benefit is that the fusebox way you write 3 lines of code in app_globals or application.cfm to lock all of the templates down and you can dynamically change the frame by just changing the fuseaction. As well, at a glance I could figure out what goes in those frames and when. So's the material on the Fusebox site - at least the presentations. There's Steve Nelson's paper, and something in French. And that's about it. Quoth Steve Nelson, 18 September: Unfortunately the techniques on the fusebox site are not completely up to date, but the docs do explain the frame work. I am pretty sure Steve, Gabe, Hale, Nat et al are pretty busy with their real jobs and its probably hard for them to take a month or two off and update the site. Most of this information flows pretty redundantly on the [EMAIL PROTECTED] list and Hal writes about it in CFDJ. However I don't find myself to be an extraordinary super programmer, and I figured most of it out after reading the fusebox docs and combing them with the CF DOCS. I'm not going to spend too much time researching something that we're not going to use, after I've already done the initial research. I stand by my claim that it's not for everybody (which is a pretty weak claim, after all). I initially researched CF 3.0. Decided there wasn't anything there that I couldn't do in the languages I was using. When 4.0 came out last year, I changed my mind and now use Coldfusion primarily. I think all recurring methods or languages are worth investigation, but then I have that kind of time on my hands. I agree that if fusebox doesn't work for your application, use what does. However I have yet to find a application that I could not or did not want to code using its methods. Sean Renet -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts.
A question I've had about Fusebox and security/stability. In some enterprise sites I've dealt with I've found it a good practice not to pass variables along the URL if possible. It becomes very easy for someone to "break" the app by altering URLs - something they actually have access to, as opposed to FORM variables, (or session client vars, etc.). If fuseactions are passed through the URL, doesn't this lead to the same "instability"? This isn't really an issue for two reasons. 1. As long as the script is filtering input correctly, and providing default options, passing the wrong attributes won't make any difference. 2. More importantly, it's not the case that the user can't tamper with form variables, or anything else that is passed from the browser (cookies, CGI parameters). It's very easy to tamper with hidden form variables - the user can simply save the HTML file locally, modify the form values to be what they want them to be, add the complete URL for the form action so that it goes to the action page on the server, load the page in their browser, and submit away. For cookies and CGI parameters, a little scripting is helpful, but that's no protection from a malicious and minimally knowledgeable user. Any data coming from the browser is subject to tampering. 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/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
Re: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts.
Dave,
You know, I think you guys at Figleaf set the standard for what client
interface should be and your applications are certainly the goal of
programmers everywhere. I also like the thought process behind what you
guys do. And I can't imagine there is anyone that does not appreciate all
the help and advice you give to our community. However, I sometimes have
issue with things that you post (e.g.., "If you can afford SQL Server, you
can afford its own box"). I have to take issue with statements you made
regarding fusebox. First of all let me state that I believe it to be "A"
methodology, not "The" methodology. I think every developer and development
team must make their own methodology decisions. That said, I think you need
to take a bit more time looking into fusebox before you make broad stroke
conversation about it. When was the last time you took a look?
For instance:
"We partition application logic between the application server
(CF), the database, the client, and potentially object tiers between the
application server and the database. Fusebox doesn't address how to manage
that complexity, so it doesn't work for us from that approach."
Wherein I do not do adult sites anymore, I have built high end, secure,
multi-tiered, object based internet/intranet fusebox applications for the
adult web industry. Three of which had a great deal of the business logic
in EJB's. One of which is being transformed into Broadvision using basically
the same methodology.
(for anyone reading this that is thinking "well that is fine for porn sites,
I build real sites", I now build high end financial web applications (money
managers, insurance companies et al) and I have yet to build one of those
that pushes the envelope of interface, traffic and security like porn does
:-P)
Also.
"We provide complex client interfaces, using frames, JavaScript, Dynamic
HTML
and Flash. It's not uncommon for our applications to have one frame
dynamically generating the contents of another. Fusebox, with its header and
footer files, is spectacularly unsuited to this."
First of all "header and footer files" are a technique, not a standard. I
actually disdain this technique, instead I use a tag.
e.g..,
cf_act_htmltags
cfinclude template="dsp_someteplate.cfm"
/cf_act_htmltags
act_htmltags-
cfparam name="caller.title" default="Sean's Example"
cfswitch expression="#thistag.executionmode#"
cfcase value="start"
html
head
titlecfoutput#caller.title#/cfoutput/title
meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"
style type="text/css"
body { font-family: arial, verdana, helvetica; color: #434343;
text-decoration: none; font=11;}
td { font-family: arial, verdana, helvetica; color: #434343;
text-decoration: none; font=11;}
td.msg { font-family: verdana, arial, helvetica; color: #327e98;
text-decoration: none; font=14;}
th { font-family: verdana, arial, helvetica; color: #737373;
text-decoration: bold; font=11;}
a { font-family: verdana, arial, helvetica; color: #330099;
text-decoration: underline; cursor: hand; font=11;}
a:hover { font-family: verdana, arial, helvetica; color: #DE8C12;
text-decoration: underline; cursor: hand; font=11;}
p { font-family: arial, verdana, helvetica; color: #434343;
text-decoration: none; font=11;}
/style
/head
body bgcolor="ff" topmargin="0" leftmargin="5" marginheight="0"
marginwidth="0" topmargin="0" leftmargin="0" marginheight="0"
marginwidth="0"
/cfcase
cfcase value="end"
/body
/html
/cfcase
/cfswitch
Any dynamic or sub application JavaScript, dhtl et al would go in a switch
where I have the stylesheet or you could just simply use a switch to path to
js or css files, all of which is determined by the fusaction. This way,
there is only one template that someone has to look at to adjust any
javascript or header and footer info site wide.
Secondly, fusebox totally supports dynamic frames
e.g..,
cfinclude template="app_locals.cfm"
CFSWITCH EXPRESSION="#attributes.fuseaction#"
CFCASE VALUE="sidenav"
cf_act_htmltags
cfinclude template="dsp_nav_side.cfm"
/cf_act_htmltags
/CFCASE
CFCASE VALUE="clientlogin"
cf_act_htmltags
cfinclude template="dsp_login.cfm"
/cf_act_htmltags
/CFCASE
CFDEFAULTCASE
cf_act_htmltags_frames
frame name="side"
src="logi/index.cfm?fuseaction=sidenavcfoutput#urltoken#/cfoutput"
marginwidth="0" marginheight="0" scrolling="no" frameborder="no" border="0"
noresize
frame name="main"
src="logi/index.cfm?fuseaction=clientlogincfoutput#urltoken#/cfoutput"
marginwidth="0" marginheight="0" scrolling="auto" frameborder="no"
border="0"
/cf_act_htmltags_frames
/CFDEFAULTCASE
/CFSWITCH
And if your frameset is dynamic, then you would just have different
fuseactions to build those framesets and have
src="logi/index.cfm?fuseaction=#attributes.fuseaction#.
"In summary, for us, it would make our applications more complex than they
have to be, and provide little or no benefit."
No, what it
RE: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts.
First: Naughty naughty!!! G !--- I wouldn't criticize the porn industry from a technological perspective; they're always on the leading edge of technology. I know why I bought my first VCR. I wish I'd started with porn sites instead of real-estate sites - one group is just more honest than the other. What I would take issue with is the idea that Fusebox is especially well-suited to n-tier applications, or especially well-suited to complex client interfaces. That's simply not the focus of Fusebox. Again, this isn't a criticism of Fusebox - I'm not saying Fusebox is "bad". What I am saying is that it's not necessarily the best approach for everything, and that using Fusebox isn't going to be a panacea for developing complex web applications. - Second: ! what would be easier for me to understand: a) using Fusebox 1. index.cfm?fuseaction=left_nav 2. index.cfm?fuseaction=main 3. index.cfm?fuseaction=cmd_frame 4. index.cfm?fuseaction=data_frame 5. index.cfm?fuseaction=socket_frame --- I encountered the exact same scenario my main frameset had a frame to display people in a 'chat room' the left nav, the main frame is the main data display frame the command frame is where you type in stuff to send to the room, the 'socket frame' is the one that actually grabs the data and rewrites the main frame and the data frame could be one that submits the data in a flciker free fashion.. That like perfectly illustrates what I did to the point where you said what I was trying to say :) I encountered the same situation where I had two UUID's to be passed to each and it was not pretty using URL parameters for loading up the frames with these values. It does work but It just felt klunky. Not wrong necesarilly or anything but klunky. If I had more time *cough cough cam cough cough* I would probably have not used Fusebox at all :p My conclusion after that application was gimme a real socket any day and ill be much happier :)) Jeremy Allen [EMAIL PROTECTED] -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts.
as opposed to FORM variables, (or session client vars, etc.). If fuseactions are passed through the URL, doesn't this lead to the same "instability"? Not really, as you should always have a CFDEFAULTCASE specified for such occasions... -Cameron Cameron Childress ElliptIQ Inc. p.770.460.7277.232 f.770.460.0963 -Original Message- From: Evan Lavidor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 19, 2000 10:15 PM To: [EMAIL PROTECTED] Subject: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts. From Dave Watts' message: a) using Fusebox 1. index.cfm?fuseaction=left_nav 2. index.cfm?fuseaction=main 3. index.cfm?fuseaction=cmd_frame 4. index.cfm?fuseaction=data_frame 5. index.cfm?fuseaction=socket_frame A question I've had about Fusebox and security/stability. In some enterprise sites I've dealt with I've found it a good practice not to pass variables along the URL if possible. It becomes very easy for someone to "break" the app by altering URLs - something they actually have access to, as opposed to FORM variables, (or session client vars, etc.). If fuseactions are passed through the URL, doesn't this lead to the same "instability"? Evan -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf _talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts.
If someone wants to produce erroneous results with your site they can as long as it only affects that user it is fine. Thats what the default fuseaction is for to catch any fuseactions not listed and handle them gracefully.. Modifying URL parameters if you code properly is not a problem since you should always do data integrity checking and bounds checking to ensure your data is safe. Jeremy Allen [EMAIL PROTECTED] -Original Message- From: Evan Lavidor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 19, 2000 10:15 PM To: [EMAIL PROTECTED] Subject: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts. From Dave Watts' message: a) using Fusebox 1. index.cfm?fuseaction=left_nav 2. index.cfm?fuseaction=main 3. index.cfm?fuseaction=cmd_frame 4. index.cfm?fuseaction=data_frame 5. index.cfm?fuseaction=socket_frame A question I've had about Fusebox and security/stability. In some enterprise sites I've dealt with I've found it a good practice not to pass variables along the URL if possible. It becomes very easy for someone to "break" the app by altering URLs - something they actually have access to, as opposed to FORM variables, (or session client vars, etc.). If fuseactions are passed through the URL, doesn't this lead to the same "instability"? Evan -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
RE: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts.
The fuseactions are simply switches and are irrelevant to obvious security measures that should be taken regardless of the development platform or coding methodology. If the application is poorly written, it won't matter whether it's in the fusebox style or not. ---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: Evan Lavidor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 19, 2000 7:15 PM To: [EMAIL PROTECTED] Subject: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox) -- Reply to Dave Watts. From Dave Watts' message: a) using Fusebox 1. index.cfm?fuseaction=left_nav 2. index.cfm?fuseaction=main 3. index.cfm?fuseaction=cmd_frame 4. index.cfm?fuseaction=data_frame 5. index.cfm?fuseaction=socket_frame A question I've had about Fusebox and security/stability. In some enterprise sites I've dealt with I've found it a good practice not to pass variables along the URL if possible. It becomes very easy for someone to "break" the app by altering URLs - something they actually have access to, as opposed to FORM variables, (or session client vars, etc.). If fuseactions are passed through the URL, doesn't this lead to the same "instability"? Evan -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf _talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebarRstsbodyRsts/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
