Warning! This is a very long and verbose response. If you're not interested
in the topic, ignore this message. Remember, I warned you!
> 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").
Why, thanks! I'm flattered! (I'm not being sarcastic, either.)
I certainly hope that you, and everyone else, occasionally takes issue with
something I say. After all, you'd be foolish to simply accept everything I
say as gospel truth. I'm certainly wrong about some things, and there's
plenty of room for disagreement on other things.
That being said, I stand by my comments both about SQL Server and Fusebox.
> 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?
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.
> 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)
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.
> "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.
One man's technique is another's standard. I'd argue that they're commonly
found in Fusebox applications, whether they're part of the "standard" or
not. The real issue is the segmentation of "display blocks", whether they
are headers or footers or something else. In either case, I'm not a fan of
that approach in all cases.
> Secondly, fusebox totally supports dynamic frames....
Sure, it supports them. There's nothing that you can't do in Fusebox. My
point, upon which I stand, is that it doesn't add anything to those
approaches. It doesn't make the code more readable, if all of the complexity
is client-side or if there are framesets. It just gives you more cfm
scripts. I'll try to illustrate what I mean, using ASCII art:
Let's say I've got a frameset:
----------------------------------------------
| | |
| | |
| | |
| | |
| | |
| 1 | 2 |
| | |
| | |
| | |
| | |
| | |
|--------------------------------------------|
| 3 | 4 | 5 |
----------------------------------------------
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
(Then, of course, I have to look at index.cfm to find out which files are
included - if the developer uses a sensible naming convention, they'll be
similar to the fuseaction attribute, I suppose.)
b) without Fusebox
1. left_nav.cfm
2. main.cfm
3. cmd_frame.cfm
4. data_frame.cfm
5. socket_frame.cfm
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.
> "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.
I would argue that the code itself, when most of the complexity is moved to
another processing tier, provides a simple enough roadmap. Most of our CFML
is pretty simple and straightforward - we've moved the complex stuff
somewhere else. At a certain point, when server-side code is simple enough,
trying to classify its components a la Fusebox makes it more complex, not
simpler.
> 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.
Well, we don't use fuseactions - generally, within our applications, the
modules are bound tightly enough to the larger application codebase that
there's a lot of cross-communication. We tend to focus our modularity on
custom tags, as appropriate.
> 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.
I'd quibble a bit about the scalability part. The more modular and
maintainable your code, the less well it will perform, all other things
being equal. For example, your use of custom tags for formatting:
> <cf_act_htmltags>
> <cfinclude template="dsp_someteplate.cfm">
> </cf_act_htmltags>
There's a relatively significant performance price with doing this,
especially if you're doing it consistently throughout your code - and you're
not counterbalancing it by building a static cache of your entire site, or
something like that. I'd agree that Fusebox code can scale, but not that it
is scalable because it's Fusebox.
> The header and footer templates are from like a year ago.
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:
"A lot of things have changed, but very few of the changes have been
published by anyone. Craig and I are releasing a Fusebox book in the next
month or so. This will have ALL of the cool new stuff."
Frankly, if I can't find out about Fusebox from the Fusebox site, you can't
really blame me for not staying on top of it as it develops.
> 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.
I never said that you couldn't use Fusebox with frames or anything else. I
simply said that it doesn't provide advantages when used within that sort of
environment. I still feel that way.
> If you have a good methodology use it, but by all means please
> research current information before you make such broad stroke
> arguments.
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).
> 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'll be happy to do so. I try to avoid making generalized statements, and I
don't think I did too badly on this topic either. I never told anyone,
"Don't use Fusebox!" I simply said that it's not for everyone, and that
developers should evaluate methodologies, like anything else in their
toolsets, based on how it fits within their development and how it can
benefit that development.
I'd like to conclude this by simply repeating the core of my earlier
argument: if Fusebox works for you, use it! If it doesn't, don't. Decide for
yourself. In my opinion, it doesn't work for our applications. If it did,
I'd be all over it in a minute. Personally, I think Steve Nelson is a smart
guy, and a nice guy. I don't have any compunction about using something "not
invented here" - there's very little on the web that hasn't been thought out
by someone before we get to it.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
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.
