Stace, while we wait for Dave's example apps and documentation of his development
approach, I thought I'd let you know that lots of examples and framework code is
available at www.fusebox.org for anyone to look at and try out.
;-)
Nice to see ya again, btw.
Brian
Hola Dave!
Any chance you'd
I was just giving Stace something to do while he waits for the small sample app he
asked about, Dave.
Dave, clearly we disagree on a fundamental level on many
topics. I don't know you, but I can tell you are an
intelligent person (maybe minus the sarcasm), so clearly you
must have reasons
I'm not going to get involved much further in this thread because just about
everything has been said. Folks who don't like Fusebox still don't like it. Folks
that like Fusebox still like it. Folks who don't know about Fusebox, or haven't
looked at it lately, might have reason to investigate
Sorry Stace, looks like no example is forthcoming.
I was just giving Stace something to do while he waits for
the small sample app he asked about, Dave.
Ah, I see. At least now, you're omitting the emoticon.
If I say that no particular structure is needed solely to organize your CF
code, why
Dave, I must admit that this is the nicest and most well-formed post I've seen from
you on this thread. Honestly I don't mean to seem like I'm calling you out when I
support people asking for sample code from you. It's just hard for me to accept
arguments from people who say there is a better
Yeah Shawn, FB has come a ways since FB2, it's a whole lot more structured and
efficient. But I confess that I fall into your second group, a person who learned
HTML first and slowly got into programming. I'd like to think I've gotten pretty good
at it, but there's always much to learn.
It's
First, I just want to be sure you understand what the fuseaction actually is. It's in
the format circuit.targetfuseaction, where the circuit part is the alias of a
Fusebox circuit, and the targetfuseaction part is the actual action within that
circuit that you want to execute. I just wanted to
the place,
instead of file names and directories)
It solves the problem by adding another one and add complexity/overhead to
your app.
Always the same dilemma : when to stop to add levels/layers of abstration...
:)
Benoit Hediard
www.benorama.com
-Message d'origine-
De : Brian Kotek [mailto
Mosh Teitelbaum wrote:
I can see how abstraction of a file's location might be beneficial, but I'm
not sure I would agree that it's a *HUGE* benefit.
It really is a big benefit.
It provides security because a would-be hacker doesn't necessarily know
where your file or files are actually located.
Dave Watts wrote:
While that may be theoretically nice, why would you have so many duplicate
links to the same thing anyway? A well-constructed site should have common,
reusable (and potentially data-driven) navigation elements. In that light,
this doesn't seem to be the huge benefit that you
Matt, the point is not whether you can abstract the logical structure from your
physical structure in other ways besides using Fusebox. Of course there are. But
Fusebox is a standard that thousands of developer know, which in and of itself is a
huge advantage. And, there are many, many more
Mosh Teitelbaum wrote:
OK, so let me flip this around a bit (no pun intended): In your experience,
how often do you have one developer working on the form and another working
on the action file? Or, more generically, how often do you have developers
working on individual files instead of groups
OK, Dave, you're clearly of the lot who will never be convinced about the benefits of
Fusebox. That's fine. But I'll go ahead and end this here so that it doesn't
degenerate into a series of tit-for-tat exchanges that won't convince anyone of
anything. Obviously, I disagree with virtually
I'm right with you Michael. I've heard from plenty of folks just itching for a chance
to rip on Fusebox (or any topic at all, actually). But when it comes to actually
delivering a superior solution, folks tend to fall suspiciously silent...
I would switch from Fusebox to something else in 5
Matt Robertson wrote:
OK here goes:
baseHRef,
ImageHRef,
AdminAreaHRef
SecurebaseHRef,
SecureImageHRef,
SecureAdminAreaHRef
BasePath
ImagePath
Multiply that by two (in the db ONLY) as my system keeps separate
values for dev and live servers. A cfif in application.cfm decides
which server it
Andrew Tyrone writes:
The phrase use what works for you comes to mind. I don't think a lot of
people that DON'T use Fusebox are opponents -- but many have credible
reasons why they don't use it.
I actually haven't really seen any specific things that people don't like about
Fusebox...just lots
Dave Watts wrote:
I don't like controller structures, or hub-and-spoke frameworks, or
whatever you want to call them. I think they add needless complexity to most
CF applications. I like being able to see a URL and know which file to edit,
without having to read some other file.
Wow, if you can
Dave, clearly we disagree on a fundamental level on many topics. I don't know you,
but I can tell you are an intelligent person (maybe minus the sarcasm), so clearly you
must have reasons for not liking Fusebox. All I can do is disagree. I tried to do it
before, but now I'll make it more
Just a note that this problem is gone in Fusebox 4.
Mike we use Fusebox heavily and the only con I have enountered (this
is FB30 and CF50) is layouts render CFFLUSH unusable.
Otherwise we like FB all the way.
Kind Regards - Mike Brunt
Original Message ---
Hey everyone,
Again, issues like this are not present in Fusebox 4. There are no cfmodule calls
necessary.
We have a fairly large site, and we have begun to componentize a lot
of the web controls such as select drop-down lists, partial displays,
and any other functions that are useable. All these
Performance in Fusebox 4 is almost 10 TIMES better than Fusebox 3. In other words, a
page that took 400 milliseconds to render in Fusebox 3 takes about 40 milliseconds to
render in production mode with Fusebox 4.
In addition to cfflush being unuseable within FB layouts, I'll also
mention that
that helps,
Brian
Brian Kotek wrote:
Performance in Fusebox 4 is almost 10 TIMES better than Fusebox 3.
In
other words, a page that took 400 milliseconds to render in Fusebox 3
takes about 40 milliseconds to render in production mode with Fusebox
4.
So what happens to all the folks who
I should have been clearer, in that the application in question used multiple CFMODULE
calls to recursively call the Fusebox core and populate several sections of content.
Other than the change from FB3 to FB4 (along with the elimination of the CFMODULEs),
no other changes were made to the
Could you be more detailed, Clint? What exactly took so long? How was it 'more than
you needed'? What version of Fusebox was used? How much experience have you had with
it?
I've been using Fusebox for years, and CF since version 3, and I've had much different
results with Fusebox. Not
with CFLDAP while using
privately-generated certificates?
Thanks in advance!
Brian Kotek
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
701 - 725 of 725 matches
Mail list logo
