First off, let me say that I have built an extremely large intranet site for
a bank that employed the concept of nesting circuits long before XFB came
out. It was just as possible then as it is now. The only difference
between what I did then and what I would do now is employe XFB to handle
traversing the circuits easier. Now I am working on sites at home and using
only XFB. They are smaller apps to be sure but I would have absolutely no
problem tranlating that intranet site into XFB and would love the
opportunity if they were willing to pay for the time (but of course, if it
ain't broke, don't fix it).
The advantage to XFB seems painfully clear to me the first time I need to
jump from circuit to circuit and when creating a circuit for the first time.
I make the circuit outsite my application and make it its own app. Once I
am happy, I copy the directory structure into the app that needs it, tweak
my circuits file in the application root, remove the circuits file from the
new circuit directory, make my points of entry and I am done.
I think the logic of turning:
admin.profiles
into:
myapp.usercontrol.admin.profiles
and intelligently starting at the root of the site, collecting what you need
as you traverse down the tree until ultimately you arrive at the "profiles"
fuseaction is incredibly easy to follow, understand and more importantly (at
least for me) teach. I have taught several people how this works and it
just seems easier than some of the standard approaches used in FB 2.0 (as of
the book printing). Several students have even had a "lightbulb" moment.
It IS just another way of looking at how you process and if I were not so
confident that I could do the same thing without XFB I would not be saying
anything, but I have. And Hal...you may not think so and perhaps I am just
too simple a man, but I think this is a very elegant approach. XFB does not
solve everything, but neither does FB...hell neither does ColdFusion! (uh
oh...anarchy).
I'm not sure (as I see some of these discussions) how I would want to handle
calling template routines outside of my home application. But realistically
I probably would not design a large scale site like that. I would probably
have a Home application umbrella that contains everything so ultimately you
would never leave the home app. That is how we did it at the bank and it
made moving entire applications much easier. Most apps were driven by
division/department/group and we found that these nebulous entities were
actually constantly moving. All we ever had to do was move the point of
entry, cut and past the sites directory (under the home app no matter what)
and blam-o (highly technical term) they were fat dumb and happy...just the
way I like my managers.
Anyway, all rambling aside, XFB may not be for everyone but I get it, I use
its technique now, I recommend it now and it definitely works for me.
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 4:54 AM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
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
