|
But
Hal, if you want the parent's fuseaction to run in exactly the same way as if
the parent were being called directly, why not just invoke the parent
directly? That's surely the simple way to ensure "that the parent will
operate in the environment it was designed to."
Let's
just imagine a simple example:
- We
have an environment variable called "request.description".
- We
have a circuit called "human" and it has two child circuits, "Lee" and
"Hal".
- The
"Human" circuit has a single fuseaction "showDescription" that simply outputs
#request.description#
- In
Human's fbx_settings, request.description="I understand sentence structure,
and can imagine the world without me in it."
- In
Lee's fbx_settings, request.description="I don't understand America date
formats."
- In
Hal's fbx_settings, request.description="I like expensive
cigars"
Now,
when the user calls "fuseaction=human.showdescription", they get "I understand
sentence structure, and can imagine the world without me in
it."
So
what result do you expect/want when the user calls
"fuseaction=hal.showdescription"?
- I
want it to say "I like expensive cigars." That's what a simple cfinclude
will do.
- Using
SuperQ(), it will say "I understand sentence structure, and can imagine the
world without me in it."
Anyway, this is probably not a discussion for this
list. We'll have to thrash this one out over a couple of brandy snifters,
and some Cuban contraband.
Thanks, matey,
Lee.
The
point of having super execute its code is that it may very well have
completely different settings than the child. For instance, the datasource it
uses may be different. The fact that SalariedEmployee is a child of
Employee does NOT mean that it has the same settings.
Before SuperQ() was available, I had to employ the workaround you
suggest, but this always bothered me. The parent MIGHT have the same
settings as the child, but that it MUST? That's a little too restrictive for
my tastes. As for complex and obscure? Well, everyone will come to
their own conclusion, but here's the call to SuperQ. It doesn't seem to me to
fit your description:
<cfset SuperQ()>
SuperQ ensures that the parent will operate in the environment it
was designed to. A simple include will not. It may be that in 99 times out of
100, they will share the same environment, but why accept a less than
complete solution? There should be some compelling reason to accept something
that can have unexpected consequences. The entire FuseQ solution was designed
to be extremely easy to use. It seems to me that this is exactly the kind of
solution we want for Fusebox: lots of power; very easy to
use.
Ahh, you honey-tongued devil,
you!
I
*want* to use the child's settings when I pass the fuseaction back up to the
parent. That's the beauty of the whole thing. FB3 winds its
way down through all of the settings to the child. The child gets to
accept of override whatever settings it wants. Then it says "Thanks
very much, my parent can take care of that fuseaction". That way, the
one fuseaction (ie the parent's) can act in different ways depending on how
the child sets up the environment.
I
wonder, in what circumstances *wouldn't* you want to use the child's
settings? I'm sure you'll throw a few at me, Hal, but that's certainly
not the way I most often want it to work. I want to use the parent's
fuseaction in the context of the child's
environment/settings. That's where you get to use the real power
of FB3 nesting. Maximum re-use, code that be used in many different
contexts, and that responds to those contexts. The
Grail!
Lee Borkman ad-libbed it slightly less well, "For
every simple problem, there's and answer that's complex, obscure... and
unnecessary." I know it doesn't have quite the same historical
resonance as Mencken, but it's Wednesday, so what can you
expect?
See ya,
LeeBB
Yes, but that won't deal with the situation where the parent's
variables set in FBX_Settings were overridden by the child. Or the child
overrode some of the settings of the grandparent. H.L. Mencken put it
best, "For every complex problem, there's an answer that's simple,
obvious...and wrong."
Hi guys,
There is a simple way to invoke the parent
circuit's fuseaction using the standard core files. I have been
doing this as a matter of routine for a long time now...
All you need to do is create the
child circuit's <cfdefaultcase> so that it cfincludes
"../fbx_switch.cfm".
It's about as simple and efficient as you could
get. If you want the child to "override" with its own version of
the fuseaction, then create the fuseaction in the child, and the
defaultcase will not be invoked. If you want the parent's
functionality, then don't create the fuseaction in the child, and the
default will be invoked, so the parent gets the call.
The standard core is VERY powerful
;-)
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
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.
|
