In that case, I can certainly see why you would want a single instance of a
module. XFB is really made for team development of large-scale applications.
For instance, the Rooms To Go ecommerce division is a completely separate
company from the parent company--but the RTG site needs info from the
corporate databases. No chance for a series of modules that work together
there.
In fact, part of what makes these sites so challenging is that the
participants WON'T play nicely together. Unfortunately, it seems to be more
the rule than the exception for me. These are typically a PITA, as we all
know, and failure rates on these is very high. I've found XFB to be
extremely helpful in solving these problems. I can see that in a snap-in
modular system, you might well want another model, like basic Fusebox--or at
least might want to adapt XFB to meet those specific needs.
OT: Years ago, I had this idea of "Snaplets"--modules that a customer could
select and that would snap in to a central framework. We worked for several
months on the idea, but politics did in the idea, which I was sad to see. I
even had a little mascot named "Snappy" -- man, it was great fun!
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: BORKMAN Lee [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 25, 2001 11:22 PM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
Hi Hal,
Re Bjork's Latest Theorem:
Actually, no, I haven't found that each customer wants their own special
security model. We have built our GlobalWebLogins application, which can be
used by every app on our Intranet, ColdFusion or not. We also have a whole
suite of global applications, GlobalFileLibrary, DatabaseEdit, etc, which
are used as components of multiple applications. When customers want
particular enhancements, I try to roll them out as new versions of the
global component. Then the various applications can be upgraded to make use
of the latest enhancements, as required. I'll be investigating the
CustomTag versioning utility that you have recommended. So I try to make
enhancements to the one globally'accessible routine. After all, if it
really is an enhancement, then I want everyone to be able to use it. I end
up with global utilities that can be called with any number of parameters,
but with default behaviour that can be invoked with just one or two
parameters.
If customers INSIST that theirs is a very special case, then I give the the
basic choice -
"okay, you can:
A) have your own built-from-the-ground-up system for $50,000 and it'll be
finished in 9 months; or
B) you can plug into the globally accessible version for $500, and we'll
have a demonstration for you to play with this afternoon."
Even public servants usually go for option B.
In fact, we have people here whose entire job is making sure that separate
instances of similar applications DON'T pop up all over the place. It's
very socialist.
On the other point, I HAVE been thinking about ways in which ancestors
applications can inherit circuit info from their descendents. The code
looks pretty ugly, I must admit, but I think you either have ugly code, or
ugly implemenation (ie clumsy duplication of circuit information). I
believe that all the ugly code (masses of evaluates, etc, and a context
"stack") could be hidden away in a single CustomTag. I'd rather suffer
whatever performance overhead there might be than rely on individual
developers to correctly copy their circuit definitions throughout multiple
circuit.cfm files. That's asking for trouble.
I'll send you my margin notes when the secretary has transcribed them ;-)
See you at one of those courses soon,
Lee.
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Dear Mr. Fermat,
I hear what you're saying about using circuits as objects. Have you actually
found this to be workable in real-world situations? What I've found is that,
for example, security module for application A at company XYZ is a
completely separate animal from the security module for application B at
company XYZ. ... This
being the case, having a central instance (single location) of a security
object is neither feasible nor desirable.
.....
On the other hand, I agree with your criticism of every circuit having to
keep track of the circuits beneath it. I originally was going to have the
code walk the directory structure, etc, but the overhead seemed outrageous.
However, I've always thought this was a kludge. It's not terribly onerous to
implement, but its inelegance bothers me and I would like to see a better
way to implement the idea. As I said in the discussion on
FormURL2Attributes, I do believe that code that isn't beautiful isn't good.
And this isn't beautiful.
So now, that the theorem of your ancestor has finally been solved, would you
care to use the margin of this email to jot down a mo' better
implementation?
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
