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>
<title><cfoutput>#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="ffffff" 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=sidenav&<cfoutput>#urltoken#</cfoutput>"
marginwidth="0" marginheight="0" scrolling="no" frameborder="no" border="0"
noresize>
<frame name="main"
src="logi/index.cfm?fuseaction=clientlogin&<cfoutput>#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 would do is provide one road map for the parent application
(main index.cfm) and individual road maps (child index.cfm's) for the sub
apps when the next programmer looks at your code.
e.g..,
<--- here is the orm sub application --->
<cfcase value="orm,ormlogin,ormfulfill,ormcomplete,ormrefuse"
delimiters=",">
<cf_act_htmltags>
<cfinclude template="orm/index.cfm">
</cf_act_htmltags>
</cfcase>
In this manner he/she will not have to spend days reading comments to figure
out what does what in your application, rather they could read the comments
on the index pages and figure out what they need to adjust quickly. This
also provides 3 lines of code in your application.cfm to lock anything down.
Also, I am sure that there has to be some modularity to your coding
practices, so it allows you not to spend the time cutting and pasting
display code, instead you just "plug it in" with a fuseaction.
In summary, fusebox is a framework methodology. It doesn't matter what you
do inside of it. It provides a framework built on code reusability that is
easy to read, implement and scale. The header and footer templates are from
like a year ago. And I have NEVER had a problem with frames or dynamic
javascript and DHTML. I can't think of one application that I have built
without frames. Flash is built into your templates, so it is really not an
issue for the framework. However, if you are using SMIL files as a
quarterback between your FLASH and REAL files, fusebox allows your
quarterback to think easier.
If you have a good methodology use it, but by all means please research
current information before you make such broad stroke arguments. Again, I
think you guys at Figleaf are the best development team across the board,
and with that there is some responsibility you should shoulder for
generalized characterizations.
I hope this sheds dome light on the ongoing development of this methodology.
Sean Renet
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
