|
Using
a global variable and then calling the parent as you've done IMHO violates the
principle of encapsulation. In your example, a much better idea would be to pass
"description" as an argument. Here's a more real world
situation:
I want
to create a SalariedEmployee. In order to do so, I want to create a generic
Employee first and get an employeeID returned to me. With that information, I
can then fill in the part that's specific to a SalariedEmployee. When I want to
create a new SalariedEmployee, I first call SuperQ(). Same with
ContractEmployee. The idea is that HourlyEmployee, SalariedEmployee, and
ContractEmployee are all types of Employee and I want to abstract the code
common to all three types of employees to the super type, Employee, so that I
don't have code duplication.
This
is how Super() is used most commonly in languages like Smalltalk and Java. In
the case I describe, I definitely want the parent's fuseaction to run in the
context the architect intended it to be. What you're describing is a sort of
reverse inheritance where the parent inherits from the child. That is downright
funky. However, I will take you up on the brandy and fine Cuban cigars.
;-)
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
;-)
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.
==^================================================================
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
==^================================================================
|
