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. They don't use the same databases, don't run on the same
servers, etc. They are, for all intents and purposes as separate as if they
were being deployed for separate companies. There are all sorts of reasons
for this--some of them technical; others political, but they exist. This
being the case, having a central instance (single location) of a security
object is neither feasible nor desirable.
On the other hand, the code for both these modules may be exactly the same,
so the kind of reuse that I'm talking about is from the developer's POV.
I've written this security (or whatever) module for application A for
company XYZ; Now I need another security module for application B for
company ABC. I may not be able to have a single runtime module that handles
all applications for a single company (just as I can't have a single
application that handles everything), but I can reuse the code for this. In
other words, the reuse occurs at design time and not at run time.
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?
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 10:10 PM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
I'm puzzled about how XFB promotes code re-use above and beyond "normal" FB.
Probably my concerns will be answered when I get over there to attend one of
Hal's courses.
As I understand it, with XFB, you "re-use" code (eg., a login routine) by
making a copy, and placing it under the new application's tree. Is that
correct? If that's so, then it's only a very primitive form of re-use.
Making separate clones of the code you wish to re-use, and distributing all
of these copies throughout your applications does not amount to substantial
re-use. What happens when you want to enhance your login routine? Do you
then have multiple versions lying around, all out-of-synch? Surely the goal
is to have one single login routine, in one single location, and to CALL it
from each of your multiple applications.
Using "normal" FB, substantial re-use is accomplished simply by means of
CFMODULE, or by the CF_ReturnFuseAction tag, depending on the situation.
How is this done under XFB? I'm sure it can be done, but the documentation
I have read concentrates on "nesting" of component applications. True
nesting is incompatible with single-location code re-use. After all, a
single piece of code simply CAN'T be nested under multiple trees - it has to
be COPIED (unless you are using symbolic links to fudge it). I have
discovered an ingenious proof of this, but unfortunately I don't have room
here in the margin to write it all down... In other words, nesting
circuit-applications make sense in terms of breaking down and organising an
application, but it has little relevance for code re-use, which (as Hal has
often told us) is surely the holy grail of programming.
I believe that XFB can be altered somewhat to allow "nested" circuits that
actually reside outside the home circuit's tree. XFB uses circuits.cfm to
register the existence and location of circuit applications WITHIN the
current application tree - I think this technique could be modified to allow
the circuits to reside ANYWHERE in the web-tree.
I also have some concerns about the need to register a low level circuit in
each and every ancestor's circuits.cfm. I'd like to see inheritance of
circuit definitions moving from descendants back up through their ancestors.
So each level of the application would only need to be told about its direct
children, but could find out about it's grandchildren, great-children, etc,
indirectly.
If that were done, then XFB would have real re-use, as well as the XFB
advantages of inherited variables, etc. Furthermore, redundant/duplicate
definitions in circuits.cfm files would be remedied.
Thanks all if you're listening...
Bjork
-----Original Message-----
From: David Sparkman [mailto:[EMAIL PROTECTED]]
I think that I'll chime in on the subject of "extended" fusebox or "nested
fuseboxes." XFB solves one major hurdle that fusebox out of the "box" does
not really solve, and that is large team development projects. With XFB, it
is easier to break out large projects in nice sized blocks for developers to
work on. It frees developers from several bottle necks that can come up in
large teams developing code simultaneously. A developer can work on their
sub application in an autonomous fashion, that is then is glued together by
the system architect that is heading up the project.
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
