Here's how well XFB handles post-launch changes and new requirements: One
week after launching Rooms To Go, the sales numbers were so good that the
CEO of Rooms To Go asked us to do everything in our power to get a separate
site up: Rooms To Go Kids. I won't go into all the complexities, but this
site was not a clone of Rooms To Go. He asked us to get it up in three
months. BECAUSE OF XFB, I was able to get the site up ONE MONTH EARLY.
For those who have never used XFB in a large-scale application, in a
development environment under stress, I ask you to consider this: XFB is a
single methodology that begins with wireframes, prototypes with DevNotes,
Fusedocs, Query Sims, assertions, and test harnesses. Nat, does it seem
likely to you is that somehow, in the midst of this, I suddenly lost my mind
and created something so obviously fatally flawed?
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: Nat Papovich [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 12:57 AM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
As projects expand, go through revisions, and continue to add functionality
post-launch, potentially large portions of the whole application can be
successfully implemented outside of the initial architecture. At this point,
the ability to reuse existing portions of an application, nested or in a
different circuit, different server, different application even, becomes
crucial. This is when you thank your lucky stars that you scoped all your
vars attributes and that you can successfully call an exisiting circuit with
cfmodule.
This kind of situation (massive systems that grow beyond initial successful
launch) is something that I see could prove difficult for XFB to handle,
with it's nesting of circuits. And I think Lee BB might be onto this... Do
you have any thoughts on this, Hal? It seems like much of XFB's strong
points are working with clearly defined, pre-launch applications.
NAT
> -----Original Message-----
> From: BORKMAN Lee [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, March 25, 2001 9:01 PM
> To: Fusebox
> Subject: RE: Musings on Attributes (was Best Practices...)
>
>
> Yeah, but this presumes that you already know everything, at the design
> stage, about the possible environments in which your fuse will be called.
> And that surely precludes the fuse from being re-used in different
> circumstances.... Oh dear, I'd love to re-use that fuse over HERE, but it
> blows away variable X, Y and Z!!
>
>
> -----Original Message-----
> From: Hal Helms [mailto:[EMAIL PROTECTED]]
>
> Well, the whole idea of XFB is that you DO know EXACTLY what vars you're
> getting in before you write the first line of code (via Fusedocs). I treat
> ALL scopes as a single entity in thinking about naming, so I
> would not have
> a local variable with the same name as a request variable, an attributes
> variable, etc. I find this is just integral to the way I write code and I
> would be very uneasy with relying on scopes to differentiate
> variable names.
>
>
> IMPORTANT NOTICE:
> This e-mail and any attachment to it is intended only to be read
> or used by
> the named addressee. It is confidential and may contain legally
> privileged
> information. No confidentiality or privilege is waived or lost by any
> mistaken transmission to you. If you receive this e-mail in error, please
> immediately delete it from your system and notify the sender.
> You must not
> disclose, copy or use any part of this e-mail if you are not the intended
> recipient. The RTA is not responsible for any unauthorised alterations to
> this e-mail or attachment to it.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
