Hal-
One of the things I seem to be running into is the number of templates
that get called/included to get the output of a deeply nested fuse due
to the inheritance.
Is the processing time not a factor or have I done something wrong
(note this one came up pretty quick, but sometimes i'll see a real
bottleneck on the various index files)?
281 milliseconds
0 ms \CUSTOMTAGS\BODYCONTENT.CFM
47 ms \CUSTOMTAGS\FORMURL2ATTRIBUTES.CFM
0 ms \CUSTOMTAGS\FORMWRAP.CFM
15 ms \CUSTOMTAGS\NESTING.CFM
15 ms \CUSTOMTAGS\SESSION.CFM
46 ms \ADMIN\INDEX.CFM
15 ms \ADMIN\LISTINGS\DSP_MYLISTINGS_FORSALE.CFM
32 ms \ADMIN\LISTINGS\INDEX.CFM
0 ms \ADMIN\LISTINGS\MYGLOBALS.CFM
0 ms \ADMIN\LISTINGS\QRY_MYLISTINGS_FORSALE.CFM
0 ms \ADMIN\MYGLOBALS.CFM
0 ms \APPLICATION.CFM
16 ms \APP_LAYOUT.CFM
0 ms \BLOCKS\DSP_CIRCUITNAVLISTINGS.CFM
0 ms \CIRCUITS.CFM
0 ms \COMMON\STYLEDEFAULT.CFM
0 ms \DSP_FOOTERMASTER.CFM
0 ms \DSP_HEADERMASTER.CFM
32 ms \INDEX.CFM
32 ms \MYGLOBALS.CFM
0 ms \ONREQUESTEND.CFM
31 ms STARTUP, PARSING, & SHUTDOWN
--
Michael Rahmn ~ <mailto:[EMAIL PROTECTED]>
| -----Original Message-----
| From: Hal Helms [mailto:[EMAIL PROTECTED]]
| Sent: Monday, March 26, 2001 7:46 AM
| To: Fusebox
| Subject: RE: reusing circuits (was Musings on Attributes)
|
|
| Yep, the reason I was able to get RoomsToGo Kids up so
| quickly was the
| ability to reuse code--not as in cut and paste, but as in
| treating the
| entire RTG site, which until then had been a standalone
| app, as a nested
| fusebox in a SUPER site which worked with both RTG and RTG
| Kids. Later, when
| they decide to build some other RTG sites, we'll make those
| nested fuseboxes
| of the super site. Maybe at some distant point, the super
| site will itself
| become a child of a super super site...
|
| I understand that it's hard to really see this if you
| haven't worked with it
| on large sites in the real world, but it really is a pretty
| wonderful thing
| to drag and drop an entire application, with virtually no
| changes to the
| code. You've heard from people (including me) who have
| built some very large
| applications with XFB and have been pleased with the simplicity and
| coherence of the approach. For some, though, XFB won't
| appeal and I'm not
| trying to win converts. For instance, I find Fusedocs and
| XFAs absolutely
| integral to writing robust, scalable, reusable and
| maintainable code. But
| some people don't like them--just as some people don't like
| Fusebox in any
| flavor. I wish them ALL the best; I just wanna write great code.
|
|
|
| Hal Helms
| Team Allaire
| [ See www.halhelms.com <http://www.halhelms.com> for info
| on training
| classes ]
|
|
| -----Original Message-----
| From: Steve Nelson [mailto:[EMAIL PROTECTED]]
| Sent: Monday, March 26, 2001 10:34 AM
| To: Fusebox
| Subject: Re: reusing circuits (was Musings on Attributes)
|
|
| I agree completely with your statement about reuse among different
| companies/sites can be separate wild animals.
|
| BUT... think about the reuse from within the same site.
|
| Example:
|
| Look at these URLs:
| http://www.secretagents.com/help/index.cfm?fuseaction=answer
| form&question_id
| =5
| http://www.secretagents.com/stats/reports/index.cfm?fuseacti
| on=sitestats
| http://www.secretagents.com/stats/reports/index.cfm?fuseacti
| on=browserreport
|
| If you try to go to any of them, you'll see that they ALL
| will kick you
| over to the "fuseaction=loginform" in the "/members"
| circuit. That is
| because you need to be logged in with correct permissions
| to view the
| pages.
|
| I'm not reusing this across multiple sites (i.e. all of
| these circuits
| are within secretagents.com), but I am reusing them across multiple
| circuits within the same site.
|
| (This uses the <cf_returnfuseaction> tag with the
| app_secure.cfm/app_login.cfm/app_logout.cfm files, which
| I'll post one
| of these days)
|
| Steve Nelson
| Try my CFML code tester for free!
| http://www.secretagents.com/tools/stomp/
| (804) 825-6093
|
| Hal Helms wrote:
| >
| > 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
