|
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 ;-)
thanks,
LeeBB
----- Original Message -----
-----
Original Message -----
From: "Jeff Peters" <[EMAIL PROTECTED]>
>
That's what the SuperQ() function is about. You can place
the
> fuseaction in the parent of the three, then call it
by:
> SuperQ(fuseaction)
>
> - Jeff
>
> On
Tuesday, May 21, 2002, at 01:45 PM, craig girard wrote:
>
>
> I have a question concerning MVC I am hoping someone might be able
to
> > shed
> > some light on. In the example
documentation on techspedition.com Hal
> > shows
> >
there being three roles for using the fictional site. Those roles
are
> > Admin/CSR/Guest.
==^================================================================
This email was sent to: [EMAIL PROTECTED]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bU4xFm
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.
==^================================================================
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
==^================================================================
|
