-- Topica Digest --
RE: Help with FB3 on CFMX
By [EMAIL PROTECTED]
RE : security
By [EMAIL PROTECTED]
Investigating FuseBox for possible port to Lasso 6
By [EMAIL PROTECTED]
RE: security
By [EMAIL PROTECTED]
Re: Help with FB3 on CFMX
By [EMAIL PROTECTED]
RE: First Impressions of ColdFusion MX
By [EMAIL PROTECTED]
So where to? (was: re: First Impressions of ColdFusion MX)
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
RE: faq - request vars
By [EMAIL PROTECTED]
Re: So where to? (was: re: First Impressions of ColdFusion MX)
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
RE: faq - request vars
By [EMAIL PROTECTED]
So where to? (was: re: First Impressions of ColdFusion MX)
By [EMAIL PROTECTED]
RE: First Impressions of ColdFusion MX
By [EMAIL PROTECTED]
RE: security
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
RE: First Impressions of ColdFusion MX
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
RE: Investigating FuseBox for possible port to Lasso 6
By [EMAIL PROTECTED]
RE: First Impressions of ColdFusion MX
By [EMAIL PROTECTED]
------------------------------------------------------------
Date: Mon, 7 Oct 2002 18:33:59 +0000
From: Marwan Saidi <[EMAIL PROTECTED]>
Subject: RE: Help with FB3 on CFMX
Jeff, Matt, that was it. Thanks!
<doh!>
Matt Jones wrote:
First, make sure you are including the cf 5 core file. If you are using
logic to determine this, then you will need to account for the version
increase
------------------------------
Date: Mon, 7 Oct 2002 14:37:46 -0400
From: [EMAIL PROTECTED]
Subject: RE : security
As I remember it, fusebox book (Peters & Papovich) said to use option #2.
You can use Secure.cfm from Hal Helms web site along with that:
http://www.halhelms.com/index.cfm?fuseaction=code.detail
HTH
Gilles
-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Envoy� : October 7, 2002 14:31
� : [EMAIL PROTECTED]
Objet : security
I know that this topic has been touched on before, however I believe
that this is a little different. We are using ColdFusion 5 and Fusebox
3 and are trying to determine which security scenario is the one to use
as our standard. Up to this point, most of our applications have been
either a public app or a secure app. We want to start combining them
and would like get some other opinions as to how... Assumption: an
application with 3 circuits, 2 are public, one is secured via and ACL
group. Option 1 - treat the secure circuit as an application (having
all of the FBX_ files in it's circuit directory [basically an
application within an application]). Option 2 - treat all 3 circuits as
circuits, but enforcing an ACL login when a user attempts to access the
secure circuit. If you have a better method, I am eager to hear it...
Opinions for or against these options are welcome.
Thanks..........
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
------------------------------
Date: Mon, 07 Oct 2002 13:41:00 -0500
From: Chris Corwin <[EMAIL PROTECTED]>
Subject: Investigating FuseBox for possible port to Lasso 6
Greetings, all.
I have kept an eye on Fusebox since v.2, and have finally decided to
investigate it further.
I *may* be interested in porting FB to Lasso 6.
Doing so would be a considerable investment in time on my part, as I do not
know the first thing about PHP nor ColdFusion, but I'm thinking of trying it
anyway.
:)
I have downloaded the core files of FB3 for both PHP and CF, and have the
PHP version running on my server (OS X Server 10.2, Apache and whatever
version of PHP comes with the Xserve).
I have to say that the CF code is a tad more comprehensible to me in some
places, but the PHP code is in others, so I guess I'm going to be
referencing both as I look into this further and decide whether or not to
try the port.
I have visited several FB-related sites in the past few days, and have a
pretty good feel for the online resources, but by all means, if there's a
"comprehensive" listing that's not easily found from FuseBox.org (and the
sites that'r 1/2 clicks away from that), don't hesitate to let me know.
Also, is there an archive of this list somewhere?
At topica.com I seem to be able to see only the last 25 messages or so--am I
doing something incorrectly?
So, in anycase, that's that. Just wanted to say "Hello."
"Hello."
:)
� - me
��������� me = chris corwin
������ title = usability czar
���� company = sonar studios
������ phone = 317.972.4210
============================================================================
"In a future time,
children will work together
to build a giant cyborg."
------------------------------
Date: Mon, 7 Oct 2002 11:41:59 -0700
From: "Barney Boisvert" <[EMAIL PROTECTED]>
Subject: RE: security
definitely option two. Just put a check to the ACL at the top of the
secured circuit's fbx_Settings.cfm file that will disallow access to those
not on the list. That makes the assumption that the login form and
processing happen in a different circuit. If not, I would reorganize the
code so that's how it's set up, because the login process shouldn't be
considered a secured action.
If you go for option one, then you're not gonig to get to share all the
variables from the public application, because you're going to be within a
new request. No ability to nest layouts, or trickle down application
settings.
barneyb
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 11:31 AM
To: [EMAIL PROTECTED]
Subject: security
I know that this topic has been touched on before, however I believe
that this is a little different. We are using ColdFusion 5 and Fusebox
3 and are trying to determine which security scenario is the one to use
as our standard. Up to this point, most of our applications have been
either a public app or a secure app. We want to start combining them
and would like get some other opinions as to how... Assumption: an
application with 3 circuits, 2 are public, one is secured via and ACL
group. Option 1 - treat the secure circuit as an application (having
all of the FBX_ files in it's circuit directory [basically an
application within an application]). Option 2 - treat all 3 circuits as
circuits, but enforcing an ACL login when a user attempts to access the
secure circuit. If you have a better method, I am eager to hear it...
Opinions for or against these options are welcome.
Thanks..........
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
------------------------------
Date: Mon, 7 Oct 2002 14:46:47 -0400
From: [EMAIL PROTECTED]
Subject: Re: Help with FB3 on CFMX
Change the logic in index.cfm to read LTE 600 instead of LTE 700. This will
account for CFMX's version number. Or you can strip out the conditional
logic and just directly include the 50 core file from index.cfm.
- Jeff
On 7 Oct 2002 at 18:22, Marwan Saidi wrote:
> Ok, so I just moved a bunch of apps over from CF5 (where they work
> gloriously) to CFMX for testing. First thing that I notice is that none
> of my FB3 apps work. I remember seeing something about complex variables
> or some such, but I don't remember it. Anyone have some help?
>
> Whenever I fire up an FB3 app, I just get a blank white screen...
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
------------------------------
Date: Mon, 7 Oct 2002 15:22:14 -0400
From: "Hal Helms" <[EMAIL PROTECTED]>
Subject: RE: First Impressions of ColdFusion MX
Ben,
I read your article when it first came out and have heard the "Fusebox
is dead" idea bantered about by others. The idea seems to revolve on the
idea that "Now that we have CFCs, we don't need a framework." But that
argument "proves too much" as the logicians say. I've asked the same
question to everyone who puts out the idea and have never gotten ANY
answer, much less a satisfactory one. It's exactly the one Jeff asked,
"If CFCs obviate the need for a framework (like Fusebox), then why don't
true objects remove the need entirely?" And yet, there are many
frameworks available for Java, and one - Struts - is enormously popular.
CFCs are components. They can be used to build a framework, but the two
are completely different. One is a raw material; the other is built from
them - in the same way that you might take a new type of metal and build
a structural beam from it. When steel, for example, was invented, it
made possible even greater structural supports; it didn't remove the
need for them.
Hal Helms
"Java for CF Programmers" class immediately
after Macromedia DevCon.
Info at www.halhelms.com
-----Original Message-----
From: Benjamin S. Rogers [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 12:24 PM
To: [EMAIL PROTECTED]
Subject: RE: First Impressions of ColdFusion MX
> The conclusion in the article is completely specious.
> It confuses the issues of application design and
> language design.
Ouch! :)
Actually, I think my point was that the CFML language has eclipsed many
aspects traditionally associated with the Fusebox framework. The
language has overlapped the framework -- not completely, but at least to
an extent that, if future versions of Fusebox are to thrive in
ColdFusion, then Fusebox will have to adapt.
I encourage you to take a look at the list archives back a few months
and review the conversation on the article which took place then. There
were a lot of good points brought up to both backing and contradict the
points made in the article.
One key element is that I only addressed Fusebox as it pertains to
ColdFusion. Though I only care about Fusebox in as much as it helps me
program better in CFML, I should have certainly noted in the article
that Fusebox has a wider audience than just ColdFusion developers.
Another interesting discussion took place on the relationship between
Fusedocs and Fusebox. I made a point of saying in the article that, in
effect, I found the CFC explorer more useful than Fusedocs because it
was "automatic." However, that really trivializes the purpose of
Fusedocs. Again, I was speaking about Fusedocs from a personal
experience and should have pointed out some of the benefits that other
people, those folks who religiously use Fusedocs, gain from it.
Nevertheless, I think the salient points of the article are sound, if
limited to the ColdFusion Fusebox experience.
Benjamin S. Rogers
http://www.c4.net/
v.508.240.0051
f.508.240.0057
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
------------------------------
Date: Mon, 7 Oct 2002 14:41:58 -0500
From: "Jeff D. Chastain" <[EMAIL PROTECTED]>
Subject: So where to? (was: re: First Impressions of ColdFusion MX)
So given that quite a few people are stating that FuseBox and CFC's can
peacefully coexist - where does that take us?
How about some open discussion as to how can FuseBox benefit from the
inclusion of CFC's? Where do they fit into the architecture? What needs to
be adapted in FuseBox to make the most of CFC's (or any of the new
technology in CFMX)? What will any of the new technology do for the
developer or development process?
What about going beyond FuseBox - FLiP or FuseDocs - any effect on either of
these?
------------------------------
Date: Mon, 7 Oct 2002 15:49:28 -0400
From: "Ken Beard" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
yep so basically we're at the point where we agree that some circuits will
have unbreakable bonds. My original question was a best practices question.
given:
circuit A
circuit B having an unbreakable bond to A
circuit b uses circuit a's query.
is it better to have circuit b call the query like
<cfmodule template="#self#" fuseaction="circuitA.queryname">
or
<cfinclude template="#pathTo('circuitA','cf')#qryQueryName.cfm">
?
any reasons besides performance in either direction? the modularily of
cfmodule makes it easy to make sure only the parameters you want are getting
passed to the query you're using. But I have a custom tag called
cf_querybox that just cfincludes the specified file, which makes it easy to
isolate a query you normally cfinclude whenever you need to. So now i can't
think of a good reason to use the fuseaction method.. but a little birdie in
my ear is telling me there's a reason out there. wondering if someone on
this list has it.
ken
-----Original Message-----
From: Barney Boisvert [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 04, 2002 6:27 PM
To: [EMAIL PROTECTED]
Subject: RE: paths in fb3
Patrick McElhaney wrote:
> If the groups circuit is assigning permissions, what is the permissions
> circuit doing?
The groups circuit is defining groups, and then assigning permissions to
those groups. But you have to create the permission list somewhere. That's
what the permissions circuit does. It also provides a place for
non-privileged users to look at what a permission means (I store a name and
description).
permissions circuit:
add permission
edit permission
insert permission
update permission
delete permission
view permission list
group circuit:
add group
edit group
insert group
update group
delete group
view group list
users circuit:
add user
edit user
insert user
update user
delete user
view user list
Within the add group and edit group fuseactions, you need to get a list of
permissions to associate with the group in question to pick which you want
to associate. That's the same query as you'll use for the view permission
list fuseaction in the permissions circuit. If you want to do it the
reverse way (edit a permission and alter the groups it's assigned to), then
you'll need the same relationship in reverse.
The same relationship exists between the users and groups circuits, just
change the names.
I've replicated this security system across three apps thus far. Each
application the permissions circuit was identical (functionally), the groups
circuit was largely untouched, and the users circuit was pretty much gutted,
because of different information being tracked, username/password
constraints, whatever.
barneyb
-----Original Message-----
From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 04, 2002 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: paths in fb3
> Barney wrote:
>
> The groups circuit flat-out can't work without the permissions circuit,
> because part of it's job is to associate permissions into groups.
If the groups circuit is assigning permissions, what is the permissions
circuit doing?
Give me some more detail. What are the fuseactions in each circuit, and
which fuseactions are sharing what fuses?
Patrick
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.391 / Virus Database: 222 - Release Date: 9/19/2002
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
------------------------------
Date: Mon, 7 Oct 2002 15:59:07 -0400
From: "Ken Beard" <[EMAIL PROTECTED]>
Subject: RE: faq - request vars
yeah exactly i've been using global because not using a structure named the
same as the file i define it in makes me feel like a mysterious and
complicated person. Or maybe i'm just a little dumb. :)
in ref the other conversation going on about paths, having this structure in
the attributes scope would make it easy to cfmodule a single file (instead
of index+fuseaction) and pass in the non-request scope settings struct.
hmm
ken
-----Original Message-----
From: Erki Esken [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 04, 2002 6:27 PM
To: [EMAIL PROTECTED]
Subject: Re: faq - request vars
> while we're at it, another GREAT item for a fusebox faq would be
> the over-use of request variables. it becomes very problematic
> when you start having an applicaiton cfmodule itself, and gets
> even trickier when different applications start cfmoduling each
> other.
That's why I use as few request variables as possible. Instead I
create a settings structure in root fbx_settings.cfm and use vars
like settings.dsn, settings.page.title etc.
.erki
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
------------------------------
Date: Mon, 7 Oct 2002 16:09:26 -0400
From: "Darron J. Schall" <[EMAIL PROTECTED]>
Subject: Re: So where to? (was: re: First Impressions of ColdFusion MX)
This is only a slightly related message. I read what you wrote, and I got a
few ideas about the direction fusebox might take.
I think it would be nice to able to add fuseactions "on the fly." It might
be that I've just been doing OOP too long, but I see something like this...
Fusebox myApp; // decalre a fusebox app to use the fusebox methods
myApp.addCircuit("admin", "admin.cfc"); // set up a circuit inthe app to use
the admin.cfc file.
myApp.addFuseAction("login", "doLogin"); // doLogin is the cffunction name
in the admin.cfc file;
Then...
myApp.invokeFuseAction("admin.login");
This is a very abstract example and I havent entirely thought it through
(it's just a whim of consciousness for me right now), but it would be a way
to get rid of the huge switch file and replace that with a cfc per
circuit... the "switch" file is then just a callback to invoking the proper
method.
Any thoughts?
-Darron
----- Original Message -----
From: "Jeff Chastain" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 07, 2002 3:41 PM
Subject: So where to? (was: re: First Impressions of ColdFusion MX)
>
> So given that quite a few people are stating that FuseBox and CFC's can
> peacefully coexist - where does that take us?
>
> How about some open discussion as to how can FuseBox benefit from the
> inclusion of CFC's? Where do they fit into the architecture? What needs
to
> be adapted in FuseBox to make the most of CFC's (or any of the new
> technology in CFMX)? What will any of the new technology do for the
> developer or development process?
>
> What about going beyond FuseBox - FLiP or FuseDocs - any effect on either
of
> these?
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
------------------------------
Date: Mon, 7 Oct 2002 16:13:04 -0400
From: "Patrick McElhaney" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
> Ken wrote:
>
> So now i can't think of a good reason to use the
> fuseaction method.. but a little birdie in my ear
> is telling me there's a reason out there.
> wondering if someone on this list has it.
Think of fuseactions as what circuits do, and fuses as how
they do it. The group circuit shouldn't know or care how the
permissions circuit gets a list of permissions, and we
should be able to change that without affecting the group
circuit.
As I said before, imagine if you decided to store
permissions in an XML file. Your fuseaction might change to
look like this:
<cfcase value="getPermissions">
<cfinclude template="act_readPermissionsFile.cfm">
<cfinclude template="act_getPermissionsFromXML.cfm">
<cfset return="attributes.permissions">
</cfcase>
Of course, the original qry_permissions.cfm no longer
exists. Barney's solution was to just change
qry_Permissions.cfm and include the code for reading/parsing
the XML there. His argument was that an XML file is just
another type of database.
That might pass for this simple example, but I don't it's
going to work very long. I don't like the idea that once a
fuse is completed, it can never be removed, and its Fusedoc
can never change, because you never know when another
circuit is reaching in and using that fuse.
Anyway, in the above example, there's already a problem. If
I have a qry_getPermission.cfm (singular), I would have to
add code that reads an XML file and then extracts a
particular permission, given an ID. The code that reads the
XML file is now duplicated in qry_getPermission.cfm and
qry_getPermissions.cfm.
Patrick
------------------------------
Date: Mon, 7 Oct 2002 16:18:47 -0400
From: "Patrick McElhaney" <[EMAIL PROTECTED]>
Subject: RE: faq - request vars
> Ken wrote:
>
> in ref the other conversation going on about
> paths, having this structure in
> the attributes scope would make it easy to
> cfmodule a single file (instead
> of index+fuseaction) and pass in the non-request
> scope settings struct.
Duh, I didn't even think about that! If your permission
circuit is using a DSN that's defined in the permission
circuit's fbx_settings and you call it directly, it won't
pick up the right DSN if you call it directly.
Patrick
------------------------------
Date: Mon, 07 Oct 2002 16:34:43 -0400
From: "John Farrar" <[EMAIL PROTECTED]>
Subject: So where to? (was: re: First Impressions of ColdFusion MX)
Added features...
The following areas in my implementation are objects...
(NOTE: This is personal and not public yet.)
* CORE - many of the "fusebox" attributes are moved here.
* SES - Session object
* APP - Application (This would be the circuit/application)
* SITE - This is an object that represents a standard interface to sites.
* User - object
This is an "implementation" of fusebox concepts and CFC's. I am not working on being
"spec" here. This is more just sharing how CFC's and fusebox "Framework" could work
together. In my implementation you would have to change some references to fusebox
variables to reference the object. To me this is good. Even if Macromedia updates
objects... the interface should stay pretty close to the way it runs now. There will
just be more and better features under the hood.
This is great for me. The user object here can be shared with flashMX. The session can
be shared with flashMX. In fact, the core could be shared with FlashMX if there were a
need. We are using a SES because we want to manage the session as an object.
This is great for us, objects/settings/methods ... think like
nouns/adjectives/verbs(commands). If you hate english, just ignore the last reference.
The point is there are many aspects to using objects that are better to ME. I like the
concept of building a "team" of objects to get work done. You plan out the job
description of all the team members. The team members have a standard interface that
can be shared amoung sites/applications/technologies. Each team member has a job to
do, and is built accordingly. The best part about this is the person who calls on the
team member from the core framework does not need to know what goes on inside the team
member. It would be like hiring an accountant. You don't do brain scans on them to see
how they do the accounting. You just get one who can do the job. The same is true of
cfc's. You are building team members to do the job and do it right. It is not a matter
of how it is done inside, unless you are building the object.
This moves data access to objects, and pulls the display logic out of the core code
also. I like the idea of creating an isolated set of objects to manage display. This
is taboo with some, they can just not use my display objects. The benefit I see in
this is the core programmers of a site are able to use the objects without having to
understand how to generate complex html. (The display objects are aimed at managing
HTML or other such output control.) If they want data in a grid. Designate the
query/array to be placed in a grid in a content block. It is sooo cooool!!! This also
gives the ability to create web skins. Using inherited features, like the concept in
CSS, you get a standard look and feel. If you want to modify the look and feel you
would have updated the CSS. The same goes here, update the skin... BAM!!! You could,
as we have done in the past, even have multiple skins, different ones for different
users and user selectable skins!
Enough... let me know if that shows you a bit of the joys of mixing cfc's with fusebox
type methodologies.
>>> [EMAIL PROTECTED] 10/07/02 03:41PM >>>
So given that quite a few people are stating that FuseBox and CFC's can
peacefully coexist - where does that take us?
How about some open discussion as to how can FuseBox benefit from the
inclusion of CFC's? Where do they fit into the architecture? What needs to
be adapted in FuseBox to make the most of CFC's (or any of the new
technology in CFMX)? What will any of the new technology do for the
developer or development process?
What about going beyond FuseBox - FLiP or FuseDocs - any effect on either of
these?
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
------------------------------
Date: Mon, 7 Oct 2002 16:30:34 -0400
From: "Benjamin S. Rogers" <[EMAIL PROTECTED]>
Subject: RE: First Impressions of ColdFusion MX
> I read your article when it first came out and
> have heard the "Fusebox is dead" idea bantered
> about by others. The idea seems to revolve on
> the idea that "Now that we have CFCs, we don't
> need a framework."
Hmm, that wasn't my argument at all. My argument was (and still is) that
many of the problems Fusebox tries to solve are solved more elegantly in
CFML itself. It's more like, "Now that we have CFCs, we don't
Fusebox...as it is."
Of course, nothing changes for Fusebox apps on ColdFusion 5 and earlier.
Nothing changes for Fusebox apps written in other languages. However, I
do not intend to use my Fusebox-esque framework when developing for the
ColdFusion MX platform.
> But that argument "proves too much" as the
> logicians say. I've asked the same question
> to everyone who puts out the idea and have
> never gotten ANY answer, much less a
> satisfactory one.
Well, I won't be able to help you there either. I love a good framework.
My problem is that I need a new one for ColdFusion MX. I mean, sure, I
could keep with my existing framework that I've been programming in for
years, but I believe I'd be better served to draw a line in the sand and
say "that was then, this is now."
> It's exactly the one Jeff
> asked, "If CFCs obviate the need for a
> framework (like Fusebox), then why don't
> true objects remove the need entirely?" And
> yet, there are many frameworks available
> for Java, and one - Struts - is enormously
> popular.
It's a good question...for someone who doesn't believe that a frameworks
are useful at all. :)
> CFCs are components. They can be used to
> build a framework, but the two are
> completely different. One is a raw
> material; the other is built from them
> - in the same way that you might take a
> new type of metal and build a structural
> beam from it. When steel, for example,
> was invented, it made possible even
> greater structural supports; it didn't
> remove the need for them.
Oh no! Not a metaphor! :)
Well, since we went there, I think a more apropos metaphor, given my
position, would be that, in ColdFusion 5 and earlier we had just one
size and shape steel beam, the Custom Tag. Fusebox took that beam and
fashioned it into a whole bunch of shapes and sizes so that I'd always
have the one I needed when I needed it.
ColdFusion MX gives a good deal of the same shaped and sized beams --
without Fusebox. Not all, but enough and in such a manner that I've been
experimenting with new ideas for a framework.
For instance, ColdFusion MX gives us a standardized way of referencing
CFC methods, which are roughly analogous to fuses in Fusebox. However,
CFCs themselves have not explicitly given us a way to nest layouts. So,
the question is, would it be better to keep Fusebox for its layout
nesting, adopt a new CFC based framework and build a new nested layout
mechanism, or bolt the Fusebox nested layout mechanism on to CFCs. I've
voted for the second.
Nevertheless, I'm curious to see what the Fusebox community comes up
with. I question Fusebox's ability to make the "best" use of CFCs while
retaining portability to other languages. I don't know what Fusebox is
like in other languages, nor specifically what features other languages
offer that may be analogous to CFCs, but it seems like this would be
something to be reconciled.
Benjamin S. Rogers
http://www.c4.net/
v.508.240.0051
f.508.240.0057
------------------------------
Date: Mon, 7 Oct 2002 20:34:48 +0000
From: alex artigues <[EMAIL PROTECTED]>
Subject: RE: security
The security model on halhelms.com has totally made
our application more simple. Although I don't
actually cascade the fbx_Permissions files, I just
use the one in the target circuit. (Mostly because
I don't understand how the cascading can work unless
child fuseactions are noted in the parent's
permissions files)
Now the only access control in the database is a single
group id attached to each user. The implementation
of the groups rights is all controlled with fusebox.
------------------------------
Date: Mon, 7 Oct 2002 16:43:35 -0400
From: "Ken Beard" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
you could pull that duplicated code out into a seperate fuse or fuseaction
and have those fuses or fuseactions call it.
i guess the ability to allow seriously significant change in the depended
upon circuit is a reason. seems like a pretty remote circumstance which
would probably only occur when reusing circuits or significantly overhauling
a piece of an app, since even the database structure could change and the
module a fuse method would still not require a change to the dependant
circuit if fieldnames don't change.. i'm about to undertake the largest and
most unweildly application of my career though, so i think i'll go for
maximum maintainability on this one.
if cfmodules are replaced by cfinvokes in the near future this presents an
even larger reason to call fuseactions rather than fuses.. what kind of
strange and mysterious mappings will we allow in the fusebox.circuits
structure as we enter the Age of Web Services (tm) so that a circuit could
exist as a part of this application or another, on this server or on
another, in coldfusion or another language.
hurry up future!
ken
-----Original Message-----
From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 4:13 PM
To: [EMAIL PROTECTED]
Subject: RE: paths in fb3
> Ken wrote:
>
> So now i can't think of a good reason to use the
> fuseaction method.. but a little birdie in my ear
> is telling me there's a reason out there.
> wondering if someone on this list has it.
Think of fuseactions as what circuits do, and fuses as how
they do it. The group circuit shouldn't know or care how the
permissions circuit gets a list of permissions, and we
should be able to change that without affecting the group
circuit.
As I said before, imagine if you decided to store
permissions in an XML file. Your fuseaction might change to
look like this:
<cfcase value="getPermissions">
<cfinclude template="act_readPermissionsFile.cfm">
<cfinclude template="act_getPermissionsFromXML.cfm">
<cfset return="attributes.permissions">
</cfcase>
Of course, the original qry_permissions.cfm no longer
exists. Barney's solution was to just change
qry_Permissions.cfm and include the code for reading/parsing
the XML there. His argument was that an XML file is just
another type of database.
That might pass for this simple example, but I don't it's
going to work very long. I don't like the idea that once a
fuse is completed, it can never be removed, and its Fusedoc
can never change, because you never know when another
circuit is reaching in and using that fuse.
Anyway, in the above example, there's already a problem. If
I have a qry_getPermission.cfm (singular), I would have to
add code that reads an XML file and then extracts a
particular permission, given an ID. The code that reads the
XML file is now duplicated in qry_getPermission.cfm and
qry_getPermissions.cfm.
Patrick
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
------------------------------
Date: Mon, 7 Oct 2002 16:46:57 -0400
From: [EMAIL PROTECTED]
Subject: RE: First Impressions of ColdFusion MX
These are interesting opinions, and they lead me to a question that might
help me understand your point of view. That question is this:
What, in your view, is the purpose of Fusebox?
It sounds like a silly question, but your view of what Fusebox does for you
will naturally color your perception of whether something else is a
satisfactory replacement.
- Jeff
On 7 Oct 2002 at 16:30, Benjamin S. Rogers wrote:
> Nevertheless, I'm curious to see what the Fusebox community comes up
> with. I question Fusebox's ability to make the "best" use of CFCs while
> retaining portability to other languages. I don't know what Fusebox is
> like in other languages, nor specifically what features other languages
> offer that may be analogous to CFCs, but it seems like this would be
> something to be reconciled.
>
> Benjamin S. Rogers
> http://www.c4.net/
> v.508.240.0051
> f.508.240.0057
------------------------------
Date: Mon, 7 Oct 2002 13:57:43 -0700
From: "Barney Boisvert" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
Patrick wrote:
> Anyway, in the above example, there's already a problem. If
> I have a qry_getPermission.cfm (singular), I would have to
> add code that reads an XML file and then extracts a
> particular permission, given an ID. The code that reads the
> XML file is now duplicated in qry_getPermission.cfm and
> qry_getPermissions.cfm.
As it should be. Fuses are atomic. You can't do a query without accessing
the database. If that means a CF datasource via CFQUERY great. If that
means an XML file via CFFILE, also fine. If it's a web service via CFHTTP,
that'll work too. It's all one action.
Lets say we have an update command, with some stuff in the attributes scope
to define what changes. If you definition of atomic means that the XML file
is read, then the XML file is used, then the XML file is written, (three
actions) that's one way to look at it. But I see that all as one action,
that depends on an application constant (request.dsn,
request.dsn.permissionsXML, request.url.permissionsXML, whatever). The rest
of the code (the other fuses, fuseactions, circuits) doesn't care what
happens, all they care is that before the fuse runs, there is some stuff in
the attributes scope, and after the fuse runs, that stuff has been recorded
to the DB, in whatever format it happens to be.
If you want to totally atomize it, then your code also needs to have one
type of file that generate SQL strings, and then another type of file that
passes the string to the database via CFQUERY.
Patrick also wrote:
> That might pass for this simple example, but I don't it's
> going to work very long. I don't like the idea that once a
> fuse is completed, it can never be removed, and its Fusedoc
> can never change, because you never know when another
> circuit is reaching in and using that fuse.
This is called backwards compatibility. Fuses shouldn't change, they should
be discrete pieces of functionality. that's the whole point of them. If
you need a different piece of functionality, make one. If I have a
paintbrush (a 4-in one) and I need one to do some decoratitve trim, I'm not
going to whip out my knife and cut off all but 30-40 bristles so I can do
it, i'm going to go get another paintbrush. The same thing applies to
fuses. They can be reused in different ways (turn the bug brush sideways,
and you have a really long 1-in brush), but their functionality shouldn't be
rewritten.
-----Original Message-----
From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 1:13 PM
To: [EMAIL PROTECTED]
Subject: RE: paths in fb3
> Ken wrote:
>
> So now i can't think of a good reason to use the
> fuseaction method.. but a little birdie in my ear
> is telling me there's a reason out there.
> wondering if someone on this list has it.
Think of fuseactions as what circuits do, and fuses as how
they do it. The group circuit shouldn't know or care how the
permissions circuit gets a list of permissions, and we
should be able to change that without affecting the group
circuit.
As I said before, imagine if you decided to store
permissions in an XML file. Your fuseaction might change to
look like this:
<cfcase value="getPermissions">
<cfinclude template="act_readPermissionsFile.cfm">
<cfinclude template="act_getPermissionsFromXML.cfm">
<cfset return="attributes.permissions">
</cfcase>
Of course, the original qry_permissions.cfm no longer
exists. Barney's solution was to just change
qry_Permissions.cfm and include the code for reading/parsing
the XML there. His argument was that an XML file is just
another type of database.
That might pass for this simple example, but I don't it's
going to work very long. I don't like the idea that once a
fuse is completed, it can never be removed, and its Fusedoc
can never change, because you never know when another
circuit is reaching in and using that fuse.
Anyway, in the above example, there's already a problem. If
I have a qry_getPermission.cfm (singular), I would have to
add code that reads an XML file and then extracts a
particular permission, given an ID. The code that reads the
XML file is now duplicated in qry_getPermission.cfm and
qry_getPermissions.cfm.
Patrick
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
------------------------------
Date: Mon, 7 Oct 2002 14:07:47 -0700
From: "Barney Boisvert" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
You don't want to break the fuse for the XML support, because then the
groups circuit needs to include several fuses. That's a job for a
fuseaction.
I've been using two UDFs since CFMX came out. runFuse("[circuit.]fuse") and
runFuseaction("[circuit.]fuseaction"). They are a hard and fast way to get
functionality across FB's internal separators.
runfuse simple does an include on the right file, after computing the
relative path from the fusebox struct.
runfuseaction is really dirty. It includes the appropriate fbx_Switch file.
It doesn't provide a complete fusebox struct for that circuit, it only
provides fusebox.fuseaction. However the goal is to do processing from a
remote location, so there shouldn't be any dependance on location within the
app (XFAs or such). This is fine for processing fusactions, but for display
fuseactions, it's a problem. However, I've found that display fuseactions
are usually within the same circuit (probably have some design issues if
they aren't), so the fusebox struct is still set up correctly for the
internal call.
So, you could add a couple fuseactinos to the permissions circuit: readfile
and savefile, which you could then call with runfuseaction from the groups
circuit. Or, better yet, you could call from the getpermissions fuseaction.
I do all my layouts this way. My content-heavy fuseactions are typically
just a table with a bunch of runfuseaction() calls in the different cells.
Much faster than CFMODULEing all over the place, and it keeps the code nice
and clean, because you have seprate fuseactions for each part. In effect,
this adds a new layer to the hierarchy: app, circuits, meta-fuseactions,
fuseactions, fuses.
These functions don't address the core issue that we've been discussing, but
they do bring the code closer to a set of objects that call methods of one
another. There is still code duplication / dependance, and there always
will be, but I like where it's going.
barneyb
-----Original Message-----
From: Ken Beard [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 1:44 PM
To: [EMAIL PROTECTED]
Subject: RE: paths in fb3
you could pull that duplicated code out into a seperate fuse or fuseaction
and have those fuses or fuseactions call it.
i guess the ability to allow seriously significant change in the depended
upon circuit is a reason. seems like a pretty remote circumstance which
would probably only occur when reusing circuits or significantly overhauling
a piece of an app, since even the database structure could change and the
module a fuse method would still not require a change to the dependant
circuit if fieldnames don't change.. i'm about to undertake the largest and
most unweildly application of my career though, so i think i'll go for
maximum maintainability on this one.
if cfmodules are replaced by cfinvokes in the near future this presents an
even larger reason to call fuseactions rather than fuses.. what kind of
strange and mysterious mappings will we allow in the fusebox.circuits
structure as we enter the Age of Web Services (tm) so that a circuit could
exist as a part of this application or another, on this server or on
another, in coldfusion or another language.
hurry up future!
ken
-----Original Message-----
From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 4:13 PM
To: [EMAIL PROTECTED]
Subject: RE: paths in fb3
> Ken wrote:
>
> So now i can't think of a good reason to use the
> fuseaction method.. but a little birdie in my ear
> is telling me there's a reason out there.
> wondering if someone on this list has it.
Think of fuseactions as what circuits do, and fuses as how
they do it. The group circuit shouldn't know or care how the
permissions circuit gets a list of permissions, and we
should be able to change that without affecting the group
circuit.
As I said before, imagine if you decided to store
permissions in an XML file. Your fuseaction might change to
look like this:
<cfcase value="getPermissions">
<cfinclude template="act_readPermissionsFile.cfm">
<cfinclude template="act_getPermissionsFromXML.cfm">
<cfset return="attributes.permissions">
</cfcase>
Of course, the original qry_permissions.cfm no longer
exists. Barney's solution was to just change
qry_Permissions.cfm and include the code for reading/parsing
the XML there. His argument was that an XML file is just
another type of database.
That might pass for this simple example, but I don't it's
going to work very long. I don't like the idea that once a
fuse is completed, it can never be removed, and its Fusedoc
can never change, because you never know when another
circuit is reaching in and using that fuse.
Anyway, in the above example, there's already a problem. If
I have a qry_getPermission.cfm (singular), I would have to
add code that reads an XML file and then extracts a
particular permission, given an ID. The code that reads the
XML file is now duplicated in qry_getPermission.cfm and
qry_getPermissions.cfm.
Patrick
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
------------------------------
Date: Tue, 8 Oct 2002 09:04:13 +0800
From: "Kay Smoljak" <[EMAIL PROTECTED]>
Subject: RE: Investigating FuseBox for possible port to Lasso 6
You might find that the fusewiki is a good resource...
http://www.meta-magic.com/cgi-bin/fusewiki
Cheers,
Kay.
______________________________________________________
Kay Smoljak Web Developer PerthWeb Pty Ltd
Level 9/105 St George's Tc - Perth - Western Australia
Ph: (08) 9226 1366 Fax: (08) 9226 1375
www.perthweb.com.au developer.perthweb.com.au
> -----Original Message-----
> From: BerberCarpet [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 8 October 2002 2:41 AM
> To: fusebox topica.com
> Subject: Investigating FuseBox for possible port to Lasso 6
>
>
> Greetings, all.
>
>
> I have kept an eye on Fusebox since v.2, and have finally
> decided to investigate it further.
>
>
>
> I *may* be interested in porting FB to Lasso 6.
>
>
>
> Doing so would be a considerable investment in time on my
> part, as I do not know the first thing about PHP nor
> ColdFusion, but I'm thinking of trying it anyway.
>
> :)
>
>
> I have downloaded the core files of FB3 for both PHP and CF,
> and have the PHP version running on my server (OS X Server
> 10.2, Apache and whatever version of PHP comes with the Xserve).
>
>
> I have to say that the CF code is a tad more comprehensible
> to me in some places, but the PHP code is in others, so I
> guess I'm going to be referencing both as I look into this
> further and decide whether or not to try the port.
>
> I have visited several FB-related sites in the past few days,
> and have a pretty good feel for the online resources, but by
> all means, if there's a "comprehensive" listing that's not
> easily found from FuseBox.org (and the sites that'r 1/2
> clicks away from that), don't hesitate to let me know.
>
>
> Also, is there an archive of this list somewhere?
>
> At topica.com I seem to be able to see only the last 25
> messages or so--am I doing something incorrectly?
>
>
> So, in anycase, that's that. Just wanted to say "Hello."
>
> "Hello."
>
>
> :)
>
> � - me
>
> ��������� me = chris corwin
> ������ title = usability czar
> ���� company = sonar studios
> ������ phone = 317.972.4210
>
>
> ==============================================================
> ==============
>
> "In a future time,
> children will work together
> to build a giant cyborg."
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
> >
------------------------------
Date: Mon, 07 Oct 2002 22:03:27 -0500
From: "Chris Brinker" <[EMAIL PROTECTED]>
Subject: RE: First Impressions of ColdFusion MX
Dan,
This is what Hal Helms had to say about the CFC argument yesteraday. It
makes a valid point that I think we concluded to anyway. Well here it is
none the less.
Chris
>Ben,
>
>I read your article when it first came out and have heard the "Fusebox
>is dead" idea bantered about by others. The idea seems to revolve on the
>idea that "Now that we have CFCs, we don't need a framework." But that
>argument "proves too much" as the logicians say. I've asked the same
>question to everyone who puts out the idea and have never gotten ANY
>answer, much less a satisfactory one. It's exactly the one Jeff asked,
>"If CFCs obviate the need for a framework (like Fusebox), then why don't
>true objects remove the need entirely?" And yet, there are many
>frameworks available for Java, and one - Struts - is enormously popular.
>
>CFCs are components. They can be used to build a framework, but the two
>are completely different. One is a raw material; the other is built from
>them - in the same way that you might take a new type of metal and build
>a structural beam from it. When steel, for example, was invented, it
>made possible even greater structural supports; it didn't remove the
>need for them.
>
>Hal Helms
>"Java for CF Programmers" class immediately
>after Macromedia DevCon.
>Info at www.halhelms.com
>
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
------------------------------
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
End of [EMAIL PROTECTED] digest, issue 964
