-- Topica Digest --
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
MVC Flow Control w/ FuseQ MX
By [EMAIL PROTECTED]
RE: MVC Flow Control w/ FuseQ MX (Moved to FBSteer)
By [EMAIL PROTECTED]
RE: MVC Flow Control w/ FuseQ MX
By [EMAIL PROTECTED]
Re: MVC Flow Control w/ FuseQ MX
By [EMAIL PROTECTED]
RE: Content Management schema
By [EMAIL PROTECTED]
FW: Flexible Menus in FB3
By [EMAIL PROTECTED]
------------------------------------------------------------
Date: Sun, 30 Jun 2002 11:49:54 +0100
From: "Neil Clark - =TMM=" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
Not at all, CFC's are should not be used for display. I am not saying
they cannot be used for it, just that they shouldn�t be.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Roger B. [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2002 22:00
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Neil Clark - =TMM= wrote:
> CFC should not be used for display at all, by all means pass a
paramter
> to the CFC which in turn can call/invoke a display layer but using
> display within a CFC itself it simply wrong.
Utter nonsense. The beautiful thing about MX is that it opens up all
sorts of possibilities. Those with a slavish devotion to objectifying
their code can go that direction... for others, CFCs can serve as really
handy web service wrappers, interesting replacements for FB switches,
custom tags with oomph, or perhaps just super-flexible UDFs.
None of those uses are wrong, simply or otherwise. And that kind of
freedom is one of the reasons I use CF in the first place.
--
Roger
------------------------------
Date: Sun, 30 Jun 2002 12:09:27 +0100
From: "Neil Clark - =TMM=" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
Take this comments from Spike, one of the best CF developers out there
at mo, and from what he understands via numerous posts with myself and
MM during the lengthy Neo beta program (1+ years)
1. CFCs should encapsulate business logic, not display logic.
2. They should return data which is rendered by the client for display.
3. The client could be Flash, Javascript, ColdFusion Custom Tags, or
some other system
4. Good CFC's allow you to change the business logic that works in the
cfc without changing the display layer and vice versa as long as you
maintain the same data types for the function input and output.
Bottom line, they should not be used for display.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Neil Clark - =TMM= [mailto:[EMAIL PROTECTED]]
Sent: 30 June 2002 11:50
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Not at all, CFC's are should not be used for display. I am not saying
they cannot be used for it, just that they shouldn�t be.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Roger B. [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2002 22:00
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Neil Clark - =TMM= wrote:
> CFC should not be used for display at all, by all means pass a
paramter
> to the CFC which in turn can call/invoke a display layer but using
> display within a CFC itself it simply wrong.
Utter nonsense. The beautiful thing about MX is that it opens up all
sorts of possibilities. Those with a slavish devotion to objectifying
their code can go that direction... for others, CFCs can serve as really
handy web service wrappers, interesting replacements for FB switches,
custom tags with oomph, or perhaps just super-flexible UDFs.
None of those uses are wrong, simply or otherwise. And that kind of
freedom is one of the reasons I use CF in the first place.
--
Roger
------------------------------
Date: Sun, 30 Jun 2002 08:37:23 -0500
From: "Foster, Lee" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
I totally agree, CFC should not be used for displays. They should be used
for things like the old app_globals, app_local and to replace the old custom
tags at least in part. I guess I can best say this another way. The CFC's
should be used to store global functions/procedures and local
functions/procedures (circuit). Now I haven't dived into MX yet but in some
or most cases (I'm not currently sure) it could be used to replace custom
tags completely.
If I remember correctly Hal wanted this thread moved to FBSteer. Please
lets do as Hal asked. I belong to far more mailing lists that I can keep
track of. But Hal asked so I finally joined FBSteer. So much e-mail; so
little time.
Lee Foster
(e)consultant, Web developer, Web Architect
[EMAIL PROTECTED]
615-834-1876
http://www.l3enterprises.com
Nashville, TN
-----Original Message-----
From: Neil Clark - =TMM= [mailto:[EMAIL PROTECTED]]
Sent: Sunday, June 30, 2002 6:09 AM
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Take this comments from Spike, one of the best CF developers out there
at mo, and from what he understands via numerous posts with myself and
MM during the lengthy Neo beta program (1+ years)
1. CFCs should encapsulate business logic, not display logic.
2. They should return data which is rendered by the client for display.
3. The client could be Flash, Javascript, ColdFusion Custom Tags, or
some other system
4. Good CFC's allow you to change the business logic that works in the
cfc without changing the display layer and vice versa as long as you
maintain the same data types for the function input and output.
Bottom line, they should not be used for display.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Neil Clark - =TMM= [mailto:[EMAIL PROTECTED]]
Sent: 30 June 2002 11:50
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Not at all, CFC's are should not be used for display. I am not saying
they cannot be used for it, just that they shouldn't be.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Roger B. [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2002 22:00
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Neil Clark - =TMM= wrote:
> CFC should not be used for display at all, by all means pass a
paramter
> to the CFC which in turn can call/invoke a display layer but using
> display within a CFC itself it simply wrong.
Utter nonsense. The beautiful thing about MX is that it opens up all
sorts of possibilities. Those with a slavish devotion to objectifying
their code can go that direction... for others, CFCs can serve as really
handy web service wrappers, interesting replacements for FB switches,
custom tags with oomph, or perhaps just super-flexible UDFs.
None of those uses are wrong, simply or otherwise. And that kind of
freedom is one of the reasons I use CF in the first place.
--
Roger
------------------------------
Date: Sun, 30 Jun 2002 13:53:57 -0400
From: "Jeremy Firsenbaum" <[EMAIL PROTECTED]>
Subject: MVC Flow Control w/ FuseQ MX
This is a multi-part message in MIME format.
------=_NextPart_000_0009_01C2203D.944AF730
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
This is a question about how to manage flow control when using an MVC architecture.
I'm using an authentication check on login for an example. Prior to MX we had to
cfmodule everything from the controller circuit, which allowed you to put conditional
logic for display in the controller.
Here's a simple login controller fuseaction:
<cfcase value="authenticate">
<cfset XFA.authenticate = "mLogin.authenticate">
<cfset XFA.failure = "dLogin.login">
<cfset XFA.success = "cMain.home">
<cfmodule ... fuseaction="#XFA.authenticate#">
<!--- *** Here's the controller determining display *** --->
<cfif isAuthenticated>
<cfmodule ... fuseaction="#XFA.success#"">
<cfelse>
<cfmodule ... fuseaction="#XFA.failure#">
</cfif>
</cfcase>
Now with FuseQ you can't do this kind of check in the controller because the AddToQ
call is not executed immediately as it is with cfmodule. So I can't get a return on
the authentication check before I determine which display fuseaction to use. One
solution is to move the model out of the fusebox architecture and completely into
CFC's. This enables you to make calls to the cfc as such:
<cfcase value="authenticate">
<cfset XFA.failure = "cLogin.login">
<cfset XFA.success = "cMain.home">
<!--- *** Here's the call to the security model CFC *** --->
<cfscript>
isAuthenticated = SecurityCFC.authenticate(attributes.j_username,
attributes.j_password);
</cfscript>
<!--- *** Here's the controller determining display using the CFC *** --->
<cfif isAuthenticated>
<cfset AddToQ(XFA.success)>
<cfelse>
<cfset AddToQ(XFA.failure)>
</cfif>
</cfcase>
Without this approach the logic would seem to have to go in the model, which would
then make another call back out to the controller (cLogin.loginFailed or
cLogin.loginSucceeded) whose job then is really just to call the appropriate display
handler. In that case, the controller really isn't controlling the flow - it's
bouncing back and forth between controller and model. But if the model is just
supposed to handle data processing and the controller is supposed to determine which
data to process and output, then how can this be done without either of the two
approaches (cfmodule or cfc) outlined above?
We haven't seen too many real examples of a true fusebox MVC architecture, but it
seems like most people still have the model as a fusebox. Any feedback is appreciated.
Jeremy Firsenbaum
The Dalton School
NYC
------=_NextPart_000_0009_01C2203D.944AF730
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4913.1100" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>This is a question about how to manage flow control
when using an MVC architecture. I'm using an authentication check on
login for an example. Prior to MX we had to cfmodule everything from the
controller circuit, which allowed you to put conditional logic for
display in the controller. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Here's a simple login controller
fuseaction:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><cfcase value="authenticate"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.authenticate =
"mLogin.authenticate"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.failure =
"dLogin.login"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.success =
"cMain.home"><BR></DIV></FONT>
<DIV><FONT face=Arial size=2> <cfmodule ...
fuseaction="#XFA.authenticate#"></FONT></DIV>
<DIV><FONT face=Arial size=2><!--- *** Here's the controller determining
display *** ---></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfif
isAuthenticated></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfmodule
... fuseaction="#XFA.success#""></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfelse></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfmodule
... fuseaction="#XFA.failure#"></FONT></DIV>
<DIV><FONT face=Arial size=2> </cfif></FONT></DIV>
<DIV><FONT face=Arial size=2></cfcase></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Now with FuseQ you can't do this kind of check in
the controller because the AddToQ call is not executed immediately as it is
with cfmodule. So I can't get a return on the authentication check before I
determine which display fuseaction to use. One solution is to move the
model out of the fusebox architecture and completely into CFC's.
This enables you to make calls to the cfc as such:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><cfcase
value="authenticate"><BR> <cfset XFA.failure =
"cLogin.login"><BR> <cfset XFA.success =
"cMain.home"></FONT></DIV>
<DIV><FONT face=Arial size=2><BR></FONT><FONT face=Arial
size=2> <!--- *** Here's the call to the security
model CFC ***
---><BR> <cfscript><BR> isAuthenticated =
SecurityCFC.authenticate(attributes.j_username,
attributes.j_password);<BR> </cfscript>
<DIV><FONT face=Arial size=2><!--- *** Here's the controller determining
display using the CFC *** ---></FONT><BR> <cfif
isAuthenticated><BR> <cfset
AddToQ(XFA.success)><BR> <cfelse><BR>
<cfset
AddToQ(XFA.failure)><BR> </cfif></FONT></DIV></DIV>
<DIV><FONT face=Arial size=2></cfcase></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Without this approach the logic would seem to have
to go in the model, which would then make another call back out to the
controller (cLogin.loginFailed or cLogin.loginSucceeded) whose job then is
really just to call the appropriate display handler. In that case, the
controller really isn't controlling the flow - it's bouncing back and forth
between controller and model. But if the model is just supposed to handle data
processing and the controller is supposed to determine which data to process
and output, then how can this be done without either of the two approaches
(cfmodule or cfc) outlined above?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>We haven't seen too many real examples of a true
fusebox MVC architecture, but it seems like most people still have the model as
a fusebox. Any feedback is appreciated.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Jeremy Firsenbaum</FONT></DIV>
<DIV><FONT face=Arial size=2>The Dalton School</FONT></DIV>
<DIV><FONT face=Arial size=2>NYC</FONT></DIV>
</BODY></HTML>
------=_NextPart_000_0009_01C2203D.944AF730--
------------------------------
Date: Sun, 30 Jun 2002 14:31:00 -0400
From: "Brian Kotek" <[EMAIL PROTECTED]>
Subject: RE: MVC Flow Control w/ FuseQ MX (Moved to FBSteer)
This is a multi-part message in MIME format.
------=_NextPart_000_0061_01C22042.C15356F0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Jeremy, I'm replying over at FBSteer...
-----Original Message-----
From: Jeremy Firsenbaum [mailto:[EMAIL PROTECTED]]
Sent: Sunday, June 30, 2002 1:54 PM
To: [EMAIL PROTECTED]
Subject: MVC Flow Control w/ FuseQ MX
This is a question about how to manage flow control when using an MVC
architecture. I'm using an authentication check on login for an example.
Prior to MX we had to cfmodule everything from the controller circuit,
which allowed you to put conditional logic for display in the
controller.
Here's a simple login controller fuseaction:
<cfcase value="authenticate">
<cfset XFA.authenticate = "mLogin.authenticate">
<cfset XFA.failure = "dLogin.login">
<cfset XFA.success = "cMain.home">
<cfmodule ... fuseaction="#XFA.authenticate#">
<!--- *** Here's the controller determining display *** --->
<cfif isAuthenticated>
<cfmodule ... fuseaction="#XFA.success#"">
<cfelse>
<cfmodule ... fuseaction="#XFA.failure#">
</cfif>
</cfcase>
Now with FuseQ you can't do this kind of check in the controller because
the AddToQ call is not executed immediately as it is with cfmodule. So I
can't get a return on the authentication check before I determine which
display fuseaction to use. One solution is to move the model out of the
fusebox architecture and completely into CFC's. This enables you to make
calls to the cfc as such:
<cfcase value="authenticate">
<cfset XFA.failure = "cLogin.login">
<cfset XFA.success = "cMain.home">
<!--- *** Here's the call to the security model CFC *** --->
<cfscript>
isAuthenticated = SecurityCFC.authenticate(attributes.j_username,
attributes.j_password);
</cfscript>
<!--- *** Here's the controller determining display using the CFC ***
--->
<cfif isAuthenticated>
<cfset AddToQ(XFA.success)>
<cfelse>
<cfset AddToQ(XFA.failure)>
</cfif>
</cfcase>
Without this approach the logic would seem to have to go in the model,
which would then make another call back out to the controller
(cLogin.loginFailed or cLogin.loginSucceeded) whose job then is really
just to call the appropriate display handler. In that case, the
controller really isn't controlling the flow - it's bouncing back and
forth between controller and model. But if the model is just supposed to
handle data processing and the controller is supposed to determine which
data to process and output, then how can this be done without either of
the two approaches (cfmodule or cfc) outlined above?
We haven't seen too many real examples of a true fusebox MVC
architecture, but it seems like most people still have the model as a
fusebox. Any feedback is appreciated.
Jeremy Firsenbaum
The Dalton School
NYC
==^================================================================
This email was sent to: [EMAIL PROTECTED]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bVLfuO
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
==^================================================================
------=_NextPart_000_0061_01C22042.C15356F0
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2716.2200" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=512343018-30062002><FONT face=Arial color=#0000ff
size=2>Jeremy, I'm replying over at FBSteer...</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Jeremy
Firsenbaum [mailto:[EMAIL PROTECTED]] <BR><B>Sent:</B> Sunday, June 30, 2002
1:54 PM<BR><B>To:</B> [EMAIL PROTECTED]<BR><B>Subject:</B> MVC Flow Control
w/ FuseQ MX<BR><BR></FONT></DIV>
<DIV><FONT face=Arial size=2>This is a question about how to manage flow
control when using an MVC architecture. I'm using an authentication check on
login for an example. Prior to MX we had to cfmodule everything from the
controller circuit, which allowed you to put conditional logic for
display in the controller. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Here's a simple login controller
fuseaction:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><cfcase value="authenticate"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.authenticate =
"mLogin.authenticate"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.failure =
"dLogin.login"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.success =
"cMain.home"><BR></DIV></FONT>
<DIV><FONT face=Arial size=2> <cfmodule ...
fuseaction="#XFA.authenticate#"></FONT></DIV>
<DIV><FONT face=Arial size=2><!--- *** Here's the controller determining
display *** ---></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfif
isAuthenticated></FONT></DIV>
<DIV><FONT face=Arial size=2>
<cfmodule ... fuseaction="#XFA.success#""></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfelse></FONT></DIV>
<DIV><FONT face=Arial size=2>
<cfmodule ... fuseaction="#XFA.failure#"></FONT></DIV>
<DIV><FONT face=Arial size=2> </cfif></FONT></DIV>
<DIV><FONT face=Arial size=2></cfcase></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Now with FuseQ you can't do this kind of check in
the controller because the AddToQ call is not executed immediately as it
is with cfmodule. So I can't get a return on the authentication check
before I determine which display fuseaction to use. One solution is to move
the model out of the fusebox architecture and completely
into CFC's. This enables you to make calls to the cfc as
such:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><cfcase
value="authenticate"><BR> <cfset XFA.failure =
"cLogin.login"><BR> <cfset XFA.success =
"cMain.home"></FONT></DIV>
<DIV><FONT face=Arial size=2><BR></FONT><FONT face=Arial
size=2> <!--- *** Here's the call to the security
model CFC ***
---><BR> <cfscript><BR> isAuthenticated =
SecurityCFC.authenticate(attributes.j_username,
attributes.j_password);<BR> </cfscript>
<DIV><FONT face=Arial size=2><!--- *** Here's the controller determining
display using the CFC *** ---></FONT><BR> <cfif
isAuthenticated><BR> <cfset
AddToQ(XFA.success)><BR> <cfelse><BR>
<cfset
AddToQ(XFA.failure)><BR> </cfif></FONT></DIV></DIV>
<DIV><FONT face=Arial size=2></cfcase></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Without this approach the logic would seem to
have to go in the model, which would then make another call back out to the
controller (cLogin.loginFailed or cLogin.loginSucceeded) whose job then is
really just to call the appropriate display handler. In that case, the
controller really isn't controlling the flow - it's bouncing back and forth
between controller and model. But if the model is just supposed to handle data
processing and the controller is supposed to determine which data to process
and output, then how can this be done without either of the two
approaches (cfmodule or cfc) outlined above?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>We haven't seen too many real examples of a true
fusebox MVC architecture, but it seems like most people still have the model
as a fusebox. Any feedback is appreciated.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Jeremy Firsenbaum</FONT></DIV>
<DIV><FONT face=Arial size=2>The Dalton School</FONT></DIV>
<DIV><FONT face=Arial size=2>NYC</FONT></DIV></BLOCKQUOTE>
</BODY></HTML>
------=_NextPart_000_0061_01C22042.C15356F0--
------------------------------
Date: Sun, 30 Jun 2002 14:55:06 -0400
From: "Hal Helms" <[EMAIL PROTECTED]>
Subject: RE: MVC Flow Control w/ FuseQ MX
This is a multi-part message in MIME format.
------=_NextPart_000_00FD_01C22046.2015E2E0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Jeremy,
FuseQ is meant to allow you to set up a work process. If you need to do
immediate execution, you should use either CFCs or CFMODULE, but see if
this helps clarify how FuseQ would apply:
CONTROLLER CIRCUIT
<cfcase value="addItemToCart">
<cfset AddToQ( 'Products.checkInventory' )>
<cfset AddToQ( 'Cart.addItem' )>
</cfcase>
This makes the controller responsible for calling the
Products.checkInventory rather than making the Cart responsible for
calling it. To me, this makes the controller do what it should do --
control the work flow -- and leaves individual circuits responsible
only for themselves.
-----Original Message-----
From: Jeremy Firsenbaum [mailto:[EMAIL PROTECTED]]
Sent: Sunday, June 30, 2002 1:54 PM
To: [EMAIL PROTECTED]
Subject: MVC Flow Control w/ FuseQ MX
This is a question about how to manage flow control when using an MVC
architecture. I'm using an authentication check on login for an example.
Prior to MX we had to cfmodule everything from the controller circuit,
which allowed you to put conditional logic for display in the
controller.
Here's a simple login controller fuseaction:
<cfcase value="authenticate">
<cfset XFA.authenticate = "mLogin.authenticate">
<cfset XFA.failure = "dLogin.login">
<cfset XFA.success = "cMain.home">
<cfmodule ... fuseaction="#XFA.authenticate#">
<!--- *** Here's the controller determining display *** --->
<cfif isAuthenticated>
<cfmodule ... fuseaction="#XFA.success#"">
<cfelse>
<cfmodule ... fuseaction="#XFA.failure#">
</cfif>
</cfcase>
Now with FuseQ you can't do this kind of check in the controller because
the AddToQ call is not executed immediately as it is with cfmodule. So I
can't get a return on the authentication check before I determine which
display fuseaction to use. One solution is to move the model out of the
fusebox architecture and completely into CFC's. This enables you to make
calls to the cfc as such:
<cfcase value="authenticate">
<cfset XFA.failure = "cLogin.login">
<cfset XFA.success = "cMain.home">
<!--- *** Here's the call to the security model CFC *** --->
<cfscript>
isAuthenticated = SecurityCFC.authenticate(attributes.j_username,
attributes.j_password);
</cfscript>
<!--- *** Here's the controller determining display using the CFC ***
--->
<cfif isAuthenticated>
<cfset AddToQ(XFA.success)>
<cfelse>
<cfset AddToQ(XFA.failure)>
</cfif>
</cfcase>
Without this approach the logic would seem to have to go in the model,
which would then make another call back out to the controller
(cLogin.loginFailed or cLogin.loginSucceeded) whose job then is really
just to call the appropriate display handler. In that case, the
controller really isn't controlling the flow - it's bouncing back and
forth between controller and model. But if the model is just supposed to
handle data processing and the controller is supposed to determine which
data to process and output, then how can this be done without either of
the two approaches (cfmodule or cfc) outlined above?
We haven't seen too many real examples of a true fusebox MVC
architecture, but it seems like most people still have the model as a
fusebox. Any feedback is appreciated.
Jeremy Firsenbaum
The Dalton School
NYC
==^================================================================
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
==^================================================================
------=_NextPart_000_00FD_01C22046.2015E2E0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2712.300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff
size=2>Jeremy,</FONT></SPAN></DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff size=2>FuseQ
is meant to allow you to set up a work process. If you need to do immediate
execution, you should use either CFCs or CFMODULE, but see if this helps clarify
how FuseQ would apply:</FONT></SPAN></DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff
size=2>CONTROLLER CIRCUIT</FONT></SPAN></DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff
size=2><cfcase value="addItemToCart"></FONT></SPAN></DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff
size=2> <cfset AddToQ( 'Products.checkInventory'
)></FONT></SPAN></DIV>
<DIV><SPAN class=371125118-30062002> <FONT face=Arial
color=#0000ff size=2><cfset AddToQ( 'Cart.addItem' )></FONT></SPAN></DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff
size=2></cfcase></FONT></SPAN></DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=371125118-30062002><FONT face=Arial color=#0000ff size=2>This
makes the controller responsible for calling the Products.checkInventory rather
than making the Cart responsible for calling it. To me, this makes the
controller do what it should do -- control the work flow -- and leaves
individual circuits responsible only for themselves.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Jeremy
Firsenbaum [mailto:[EMAIL PROTECTED]] <BR><B>Sent:</B> Sunday, June 30, 2002
1:54 PM<BR><B>To:</B> [EMAIL PROTECTED]<BR><B>Subject:</B> MVC Flow Control
w/ FuseQ MX<BR><BR></FONT></DIV>
<DIV><FONT face=Arial size=2>This is a question about how to manage flow
control when using an MVC architecture. I'm using an authentication check on
login for an example. Prior to MX we had to cfmodule everything from the
controller circuit, which allowed you to put conditional logic for
display in the controller. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Here's a simple login controller
fuseaction:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><cfcase value="authenticate"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.authenticate =
"mLogin.authenticate"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.failure =
"dLogin.login"></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfset XFA.success =
"cMain.home"><BR></DIV></FONT>
<DIV><FONT face=Arial size=2> <cfmodule ...
fuseaction="#XFA.authenticate#"></FONT></DIV>
<DIV><FONT face=Arial size=2><!--- *** Here's the controller determining
display *** ---></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfif
isAuthenticated></FONT></DIV>
<DIV><FONT face=Arial size=2>
<cfmodule ... fuseaction="#XFA.success#""></FONT></DIV>
<DIV><FONT face=Arial size=2> <cfelse></FONT></DIV>
<DIV><FONT face=Arial size=2>
<cfmodule ... fuseaction="#XFA.failure#"></FONT></DIV>
<DIV><FONT face=Arial size=2> </cfif></FONT></DIV>
<DIV><FONT face=Arial size=2></cfcase></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Now with FuseQ you can't do this kind of check in
the controller because the AddToQ call is not executed immediately as it
is with cfmodule. So I can't get a return on the authentication check
before I determine which display fuseaction to use. One solution is to move
the model out of the fusebox architecture and completely
into CFC's. This enables you to make calls to the cfc as
such:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><cfcase
value="authenticate"><BR> <cfset XFA.failure =
"cLogin.login"><BR> <cfset XFA.success =
"cMain.home"></FONT></DIV>
<DIV><FONT face=Arial size=2><BR></FONT><FONT face=Arial
size=2> <!--- *** Here's the call to the security
model CFC ***
---><BR> <cfscript><BR> isAuthenticated =
SecurityCFC.authenticate(attributes.j_username,
attributes.j_password);<BR> </cfscript>
<DIV><FONT face=Arial size=2><!--- *** Here's the controller determining
display using the CFC *** ---></FONT><BR> <cfif
isAuthenticated><BR> <cfset
AddToQ(XFA.success)><BR> <cfelse><BR>
<cfset
AddToQ(XFA.failure)><BR> </cfif></FONT></DIV></DIV>
<DIV><FONT face=Arial size=2></cfcase></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Without this approach the logic would seem to
have to go in the model, which would then make another call back out to the
controller (cLogin.loginFailed or cLogin.loginSucceeded) whose job then is
really just to call the appropriate display handler. In that case, the
controller really isn't controlling the flow - it's bouncing back and forth
between controller and model. But if the model is just supposed to handle data
processing and the controller is supposed to determine which data to process
and output, then how can this be done without either of the two
approaches (cfmodule or cfc) outlined above?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>We haven't seen too many real examples of a true
fusebox MVC architecture, but it seems like most people still have the model
as a fusebox. Any feedback is appreciated.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Jeremy Firsenbaum</FONT></DIV>
<DIV><FONT face=Arial size=2>The Dalton School</FONT></DIV>
<DIV><FONT face=Arial size=2>NYC</FONT></DIV></BLOCKQUOTE>
</BODY></HTML>
------=_NextPart_000_00FD_01C22046.2015E2E0--
------------------------------
Date: Sun, 30 Jun 2002 14:56:40 -0400
From: "John Quarto-vonTivadar" <[EMAIL PROTECTED]>
Subject: Re: MVC Flow Control w/ FuseQ MX
[what does the "d" in "dLogin.login" mean?]
at least based on the example you give, I see only a semantic difference
between the CFMODULE example you gave and the CFC example. Certainly the
case for CFCs must be made on more than just a 'different way to handle
CFMODULE' basis.
>From a functional perspective your example uses them to do the same thing.
But here is another functional equivalence -- why not just use CFLOCATION?
After your CFMODULE all you're really doing is going to another page. The
example itself is somewhat "fixed" -- one can always construct singlular
examples that highlight the advantages/disadvantages of
CFMODULE/CFLOCATION/CFC/FuseQ depending on the point one wants to make.
Looking over the example, it seems to me that you really want is
that the controller method is "login", not "authenticate". "logging in"
encompasses receipt of anything coming in (such as the loginform), the
authentication *and* the resulting directives based on that authentication.
Perhaps what one can consider is the more atomic approach:
<cfcase value="login">
<cfset AddToQ( 'mLogin.authenticate' )>
<cfset AddToQ( 'cLogin.authenticate' )>
</cfcase>
<cfcase value="authenticate">
<cfset XFA.failure = "dLogin.login">
<cfset XFA.success = "cMain.home">
<cfif isAuthenticated>
<cfset AddToQ(XFA.success)>
<cfelse>
<cfset AddToQ(XFA.failure)>
</cfif>
</cfcase>
[although my own preference would still be to CFLOCATE over to XFA.success
or XFA.failure so as to force a new page request, since by the time one to
that point, the common language purpose of the original page request is
complete]
At any rate, the point is that the FuseQ approach didn't require any of the
costs that would be associated with the additional CFMODULE or CFC call(s).
In very common functionality such as logging in this will save quite a bit
of processing. In more esoteric functionality "do this template once per
calendar year" then it hardly makes a difference which of the several
approaches is used. I've found that FuseQ ends up removing a good 90% of my
former CFMODULE calls; I can live with the other 10% cuz I'm ahead of the
game either way.
As a further note, the CFMX version of FuseQ includes the method InstantQ()
which does what CFMODULE does (it just looks prettier). It makes no sense to
implement InstantQ() for CF5 since the only reason for its existance is
ease-of-typing but implementing a CFMODULE equivalent in CF5 takes a lot
more code for no real gain.
----- Original Message -----
From: "Jeremy Firsenbaum" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 30, 2002 1:53 PM
Subject: MVC Flow Control w/ FuseQ MX
This is a question about how to manage flow control when using an MVC
architecture. I'm using an authentication check on login for an example.
Prior to MX we had to cfmodule everything from the controller circuit, which
allowed you to put conditional logic for display in the controller.
Here's a simple login controller fuseaction:
<cfcase value="authenticate">
<cfset XFA.authenticate = "mLogin.authenticate">
<cfset XFA.failure = "dLogin.login">
<cfset XFA.success = "cMain.home">
<cfmodule ... fuseaction="#XFA.authenticate#">
<!--- *** Here's the controller determining display *** --->
<cfif isAuthenticated>
<cfmodule ... fuseaction="#XFA.success#"">
<cfelse>
<cfmodule ... fuseaction="#XFA.failure#">
</cfif>
</cfcase>
Now with FuseQ you can't do this kind of check in the controller because the
AddToQ call is not executed immediately as it is with cfmodule. So I can't
get a return on the authentication check before I determine which display
fuseaction to use. One solution is to move the model out of the fusebox
architecture and completely into CFC's. This enables you to make calls to
the cfc as such:
<cfcase value="authenticate">
<cfset XFA.failure = "cLogin.login">
<cfset XFA.success = "cMain.home">
<!--- *** Here's the call to the security model CFC *** --->
<cfscript>
isAuthenticated = SecurityCFC.authenticate(attributes.j_username,
attributes.j_password);
</cfscript>
<!--- *** Here's the controller determining display using the CFC *** --->
<cfif isAuthenticated>
<cfset AddToQ(XFA.success)>
<cfelse>
<cfset AddToQ(XFA.failure)>
</cfif>
</cfcase>
Without this approach the logic would seem to have to go in the model, which
would then make another call back out to the controller (cLogin.loginFailed
or cLogin.loginSucceeded) whose job then is really just to call the
appropriate display handler. In that case, the controller really isn't
controlling the flow - it's bouncing back and forth between controller and
model. But if the model is just supposed to handle data processing and the
controller is supposed to determine which data to process and output, then
how can this be done without either of the two approaches (cfmodule or cfc)
outlined above?
We haven't seen too many real examples of a true fusebox MVC architecture,
but it seems like most people still have the model as a fusebox. Any
feedback is appreciated.
Jeremy Firsenbaum
The Dalton School
NYC
------------------------------
Date: Sun, 30 Jun 2002 15:07:44 -0500
From: "Jason L. West, Sr" <[EMAIL PROTECTED]>
Subject: RE: Content Management schema
Thanks Dan
I appreciate the upload.
Jason
-----Original Message-----
From: Dan O'Keefe [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 28, 2002 13:36
To: [EMAIL PROTECTED]
Subject: RE: Content Management schema
-----Original Message-----
From: Jason L. West, Sr [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 28, 2002 12:39 PM
To: [EMAIL PROTECTED]
Subject: RE: Content Management schema
Can someone post the db in a zip here in the discussion? I would like to
use this app myself.
Thanks
Jason
-----Original Message-----
From: Erki Esken [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 28, 2002 12:28
To: [EMAIL PROTECTED]
Subject: Re: Content Management schema
> For those of you with CFMX, I found the database in
> c:\cfusionmx\db\cfexamples.mdb
>
Hmmm.. The cfexamples.mdb that came with my copy of CFMX doesn't have
the correct tables in it. But CF5's does, the publishing system tables
start with "tblPb...".
.erki
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002
------------------------------
Date: Mon, 1 Jul 2002 10:43:55 +0100
From: "Kevin Roche" <[EMAIL PROTECTED]>
Subject: FW: Flexible Menus in FB3
I decided to resurect this thread to enumerate my thoughts and look for more
feedback.
FYI Here is a summary of what happened so far.
I am in the process of redesigning an existing application including making
it use FB3 it currently a mixture of FB1 and FB2.
One of the most complex part of the current system is the menu and I was
keen to simplify that if possible. I also would like to be able to deploy
more complex menus like that in the CF Flash Component Kit. In addition we
need whatever we do with the menu to fit in with the fusebox layout concept
so that we can add menu items in the code and have them appear later when
the menu is built in the layout.
I was concerned to try and find a system where modules were a little more
separated from each other than they are in the current system. It would be
good if the menu automatically updated when new AF modules are added. (Hell
it's getting more complicated already!) To achieve this I am assuming that
in future each new module will consist of one or more new circuits. These
circuits will be placed below existing modules, so for example a module that
makes chenges to the membership circuit will have a circuit plced in a
directory below the membership directory.
In this situation it will be necessary to allow a menu building function to
accumulate the menu items from several different circuits.
As an experiment I tried the following:
1/ Built a customtag <cf_menuitem> that allows you to add new menu items to
a structure for use later.
It will cope with multiple menus if required. So you could also have a
separate right hand menu if you want.
2/ Built a customtag <cf_showmenu> that creates a simple menu using the
information in the structure.
These two tags can be used with FB3 and layouts to build a menu which shows
up on the page at layout time. To allow menus to be dynamically created when
modules are added, the first tag should be used as follows :
In FB3 the file fbx_settings is executed for each circuit in the tree above
the current one. Imagine the structure for a module that is used to set
preferences for an individual, the directories are:
/root/membership/individual/preferences/
the following files will be executed
/root/fbx_settings.cfm
/root/membership/fbx_settings.cfm
/root/membership/individual/fbx_settings.cfm
/root/membership/individual/preferences/fbx_settings.cfm
Another directory may contain a similar module for membership handling of
groups that are members of other groups. The following files will be
executed:
/root/fbx_settings.cfm
/root/membership/fbx_settings.cfm
/root/membership/group/fbx_settings.cfm
/root/membership/group/preferences/fbx_settings.cfm
The menuitem tag can then be called from fbx_settings.cfm in each circuit,
to add the basic items for the circuit.
However this only answers part of the problem as often it is necessary to
add links to a module from it parent.
For example links in the /root/membership/individual/ module that point to
/root/membership/group/preferences/ but only when the module is present.
To achieve this I suggest we place a new template in each circuit called
mnu_settings.cfm. This module could be called from it's parent directory and
would contain menu items added by the new module.
The structure fusebox.circuits always contains a list of the direcories in
the application so it can be used to find and execute these new templates.
The idea occured to me that the mnu_settings.cfm templates could be executed
for all the modules right at the start in the roots fbx_settings.cfm
template. That leads to next utility, we should ...
3/ Build a fuse that uses the structure in fusebox.circuits to find all the
mnu_settings templates.
After some research I found a freeware menu system written in Javascript and
DHTML that runs in IE4, IE5, IE6, NS4.7, NS6, and Opera. I was impressed by
its capability as a menu but since it was designed to run on plain HTML
pages not in CF needed some changes were needed. The original was by Angus
Turnbull http://www.twinhelix.com
That lead to the next step:
4/ I have built a tag <cf_showpopup> which integrates many of the functions
in Angus' script in the menu with CF. It works with the <cf_menuitem> tag.
It allows you to display dropdown menus using graphics and text and for the
background to be trnsparent.
The small questions are:
What else should this tag do?
Should there be any relationship between the menu and the XFA structure?
I am also thinking that we should make it possible to control who can
access each module by group.
Kevin
At 05:21 PM 6/24/2002 +0100, you wrote:
>Steve,
>
>Yes you have that correct now.
>
>As to categories and subcategories I would plan to allow the tag to specify
>the parent item of the item to be added, that would allow mutiple levels if
>neccessary. I have not decided how I would do that, but maybe if the item
>was a couple of levels down I would have to specify the parent's name or
>even grandparent's name if parent is not unique. For example:
>
>in simple cases
><cf_menuItem name="add" parent="Invoice" fuseaction="circuit.fuseaction">
>
>Or when needed
>
><cf_menuItem name="add" parent="Invoice">
><cf_menuItem name="special" parent="Invoice.add"
>fuseaction="circuit.fuseaction>
>
>When there is no fuseaction it becomes a parent with subitems.
>
>What do you think ?
>
>Kevin
>
>-----Original Message-----
>From: Steve Bryant [mailto:[EMAIL PROTECTED]]
>Sent: 24 June 2002 18:11
>To: [EMAIL PROTECTED]
>Subject: RE: Flexible Menus in FB3
>
>
>I must have misunderstood. Let me review my new interpretation of what you
>are saying:
>
>Each circuit will have a mnu_something file. That file could add zero or
>more menu items to the menu. If the file does not exist, no menu items are
>added.
>
>If that is what you are saying then, yes, I would say that has some
>potential.
>
>How would you handle major categories versus subcategories in menus?
>
>At 04:41 PM 6/24/2002 +0100, you wrote:
> >Steve,
> >
> >The file mnu_somthing could add as may items as it wanted to the menu. If
> >the file does not exist none would be added.
> >
> >So there is a one to zero/many ratio.
> >
> >Kevin
> >
> >-----Original Message-----
> >From: Steve Bryant [mailto:[EMAIL PROTECTED]]
> >Sent: 24 June 2002 17:20
> >To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> >Subject: Re: Flexible Menus in FB3
> >
> >
> >I like the concept. But I know that for me there is rarely (if ever) a
one
> >to one ratio between circuits and menu items. Circuits are based upon
> >logical divisions in functionality. Menu items are based upon tasks that
> >the user might want to do. They don't necessarily correlate.
> >
> >At 03:50 PM 6/24/2002 +0100, Kevin Roche wrote:
> >
> > >Hi,
> > >
> > >I have a need for a flexible menu system which will allow us to add
>modules
> > >to a fusebox application and have the new modules automatically appear
in
> > >the menus. The modules would in each case be a new circuit or two
>circuits
> > >which would be installed in a directory below one of the existing
>circuits.
> > >
> > >Has anyone else has done this?
> > >
> > >My thoughts are going in the direction of implementing it as follows.
> > >
> > >1/ Create a custom tag to add menu items. The tag would simply add the
> > >information to a structure which would be read during execution of the
> > >layout file to build the actual menu.
> > >
> > >2/ The above tag could be called any time during the execution of the
>code
> > >to add a new item to the menu.
> > >
> > >3/ At the start of processing (perhaps in fbx_settings) I would call a
> > >routine that would look in the structure created by fbx_circuits to
find
> >all
> > >the directories in the application and look for a file called
>mnu_somthing
> > >to add items to the menu.
> > >
> > >OR
> > >
> > >4/ Similar to 3 but only look below the current circuit's directory.
> > >
> > >What do you guys think ?
> > >
> > >Would this be a good way to create menus in general for fusebox ?
> > >
> > >Kevin Roche
>
------------------------------
End of [EMAIL PROTECTED] digest, issue 845
