I agree with this ;)

Clint

----- Original Message ----- 
From: "Benoit Hediard" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2003 1:23 PM
Subject: RE: Cons to Fusebox


> "it is REALLY nice to be able to edit a few lines in your circuit
> definitions and be done with it, instead of having to change links all
over
> the place."
>
> I agree with most of your points.
> But if you decide to change your fuseaction names and circuits structure,
> don't you have to change links all over the place, plus the fusebox
> configuration files?
> (fuseaction names and circuits are also "harcoded" all over the place,
> instead of file names and directories)
>
> It solves the problem by adding another one and add complexity/overhead to
> your app.
> Always the same dilemma : when to stop to add levels/layers of
abstration...
> :)
>
> Benoit Hediard
> www.benorama.com
>
> > -----Message d'origine-----
> > De : Brian Kotek [mailto:[EMAIL PROTECTED]
> > Envoyé : jeudi 17 juillet 2003 19:48
> > À : CF-Talk
> > Objet : Cons to Fusebox
> >
> >
> > First, I just want to be sure you understand what the fuseaction
> > actually is.  It's in the format "circuit.targetfuseaction",
> > where the "circuit" part is the alias of a Fusebox circuit, and
> > the "targetfuseaction" part is the actual action within that
> > circuit that you want to execute. I just wanted to make sure that
> > was clear.  So...
> >
> > Abstraction is one huge benefit of circuits.  When I do
> > "index.cfm?fuseaction=store.productdetails", I don't know, or
> > care, WHERE the store circuit is.  This applies to both the
> > logical and physical structure of the site.  Using circuit
> > aliases masks these dependencies because the core file handles
> > translation of the alias to a directory path to be called.  So as
> > a team developer creating a link to that section of the site, I
> > don't need to know anything about the application's directory
> > structure or where that part of the site is located.
> >
> > On the other hand, using
> > "/root/store/products/productdetails.cfm" in a link requires you
> > to know EVERYTHING about the physical structure of the site for
> > EVERY link.  And if for some reason I refactor the site, and part
> > of the change is to alter the physical location of my products
> > directory, or break it up into more than one directory?  Better
> > open up a lot of files or break out the extended search and
> > replace, because every link that points there is going to have to
> > be changed.
> >
> > Circuits also allow for very easy dynamic links.  If I have a
> > component that creates a form, and I want to reuse that form in
> > multiple places in the system but I want it to post to different
> > things, this is really easy with circuits.  You do: form
> > action="index.cfm?fuseaction=#xfa.formAction#".  Then at runtime,
> > you can set xfa.formAction to be anything you need it to be.
> > Bam...like magic the form can now post to any fuseaction you need
> > it to...and you never need to touch the code itself, only set the
> > xfa variable.
> >
> > Pretty much, your question goes right to the heart of why Fusebox
> > uses circuits in the first place.  The answer is that when
> > related code is grouped together, that code is easier to maintain
> > and change.  Placing code into directories can do this as well,
> > in fact Fusebox circuits are aliases for directories.  But with
> > circuits, you get that layer of abstraction between the alias of
> > the circuit and it's actual path. I can tell you from real world
> > experience that when you have to make significant changes to the
> > structure of your application, it is REALLY nice to be able to
> > edit a few lines in your circuit definitions and be done with it,
> > instead of having to change links all over the place.
> >
> > Hope that helps,
> >
> > Brian
> >
> > Mosh Teitelbaum wrote:
> > >I've been pondering the benefits and downsides of this approach
> > for a while
> > >now.  Since you bring it up, I was wondering what everyone else thought
> > >about all requests having to come in through an application
> > spine?  That is,
> > >what benefits exist and/or are perceived to exist from structuring all
of
> > >your HREFs like "index.cfm?fuseaction=foo.bar" or
> > "index.cfm?displayPage=5"
> > >instead of "/foo/bar.cfm" and "page5.cfm" respectively?
> > >
> > >Anyone?
> > >
> > >--
> > >Mosh Teitelbaum
> > >evoch, LLC
> > >Tel: (301) 942-5378
> > >Fax: (301) 933-3651
> > >Email: [EMAIL PROTECTED]
> > >WWW: http://www.evoch.com/
> > >
> >
> 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription: 
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq

Get the mailserver that powers this list at 
http://www.coolfusion.com

                                Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
                                

Reply via email to