This is almost rediculous. I've seen complete newbies with little or no
CF experience pick up fusebox in a week. Although I haven't been into
FB4 yet, the transition from FB2 to FB3 took about a half hour.

4) Fusebox does have a learning curve (IMO, a pretty steep one if you
want to
   truly and properly use all that FB offers) but once learned, you're
in
   pretty good company (until the next release and then there usually
seems to
   be another learning curve).

-----Original Message-----
From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 18, 2003 2:27 PM
To: CF-Talk
Subject: RE: Cons to Fusebox


Brian:

I appreciate all the effort you've been pouring into this thread.  That
said, allow *me* to back up a bit 8^).

I am familiar with FB3 and have had opportunities to use it and its
various features.  I've also spent some (but not enough) time going over
FB4 and I'm fairly well aware of what new features it brings to the
table.  All that said, I was never actually interested in discussing the
pros/cons of Fusebox (despite the unfortunate email subject).

I was really interested (and still am) in the pros/cons of one aspect of
Fusebox... the controller.  The central index.cfm file that all requests
must pass through.  That said, this thread has become interesting to me
in its own right.

To date, the main and generic points that I've noticed being made in
this thread are, in no particular order:

1) Some people love FB, others hate it, still others don't care, and
everyone
   seems to be very passionate about it all (except maybe for those who
don't
   care).

2) Fusebox doesn't offer anything that can't otherwise be accomplished,
however,
   it essentially prepackages it for you so you don't have to worry
about it.

3) Fusebox offers its own set of advantages and disadvantages (perceived
or
   actual) and it's up to the individual developer/architect to
determine
   whether or not the tradeoffs make sense for that developer or
project.

4) Fusebox does have a learning curve (IMO, a pretty steep one if you
want to
   truly and properly use all that FB offers) but once learned, you're
in
   pretty good company (until the next release and then there usually
seems to
   be another learning curve).

5) While I wouldn't call Fusebox the de facto ColdFusion framework
(there are
   too many people/sites not using it for that) it is certainly the most
   popular and used ColdFusion framework out there.

6) Fusebox is not a panacea.  It's just as easy to write crappy code in
FB as
   it is to write crappy code without FB.

>From my own perspective, and arguably for my own personal reasons,
Fusebox tends to be too much for me.  It doesn't overwhelm me, it just
offers too much stuff that I don't feel I need, and doesn't offer other
stuff that I do want.

It also requires a style of managing/writing code that I don't find
beneficial.  I'm willing to be flexible and change my coding style and
mannerisms when I see benefit in doing so but, again for my own reasons,
I don't find FB's way of doing things to be beneficial to what I do.

Finally, FB tends to restrict how projects can be organized.  I don't
know much about FLiP but what I do seems to be impractical for how my
own experiences suggest most projects succeed.  I recognize that any
framework will restrict to some extent how you do what you do, but I
find FB's restrictions to be too restrictive/impractical.

--
Mosh Teitelbaum
evoch, LLC
Tel: (301) 942-5378
Fax: (301) 933-3651
Email: [EMAIL PROTECTED]
WWW: http://www.evoch.com/


> -----Original Message-----
> From: Brian Kotek [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 18, 2003 10:26 AM
> To: CF-Talk
> Subject: Cons to Fusebox
>
>
> Mosh, I think we're getting wrapped up too much in specifics. Let me 
> back up for a moment.  First, XFA's are not required, only suggested.

> You can write an entire FB app without a single XFA. They just offer 
> some nice benefits, like:
>
> keeping decisions about application flow in the realm of the 
> architect. keeping decisions about application flow out of any 
> individual code file. allowing you to change at runtime how the 
> application behaves. allowing for components that respond differently 
> in different situations.
>
> So, the decision on whether or not to use XFA's is a personal one. If 
> you think this is not worth the effort (though in reality the effort 
> required is neglegible), then you aren't required to use it.
>
> Regarding reuse and the question of building up end content from 
> smaller pieces, this too is a decision, not a requirement.  But having

> the ability to do this by adding a single attribute to an XML element 
> is pretty impressive, at least to me.  Let me give a more realistic 
> example:
>
> Someone calls the controller to execute the fuseaction 
> "store.productDetails".  The store circuit is targeted, and the action

> productDetails is executed.  productDetails is a controller-level 
> action so it doesn't do anything itself. Instead it invokes a series 
> of actions in the Model and the View to complete the user's request.  
> In this case, it might call the model to query for product details, 
> and the view to output those product details.  Simple enough so far.  
> But now...
>
> We take the resulting formatted output and capture it in a variable 
> called a content component.  So we have the formatted product details 
> wrapped up in a variable.  But why stop there? The controller can call

> more fuseactions in the Model and View, maybe to get recently viewed 
> items, items similar to the current item being viewed, daily specials,

> etc.  All of these are called separately, each one is formatted, and 
> the formatted output captured in a content component variable.  So we 
> end up with a bunch of these "building block" content variables.  At 
> the end of the request, we can call a layout file that positions and 
> outputs all of the content components, formats it with global header 
> and footer, navigation, breadcrumb trail, whatever.
>
> The result is an extremely flexible layout.  "Skinning" the site so 
> that users can customize the layout is now trivial.  Altering the 
> layout is trivial.  Altering any single component in the layout is 
> trivial because each call is encapsulated.  And this is all done in 
> the circuit.xml file like this:
>
> <fuseaction name="productDetails">
>       <set name="xfa.addtocart" value="store.addproducttocart"/>
>       <set name="xfa.productdetails" value="store.productDetails"/>
>       <do action="m_products.getProductDetails"/>
>       <do action="v_pages.productDetails"
contentvariable="pageContent"/>
>       <do action="m_products.getRelatedProducts"/>
>       <do action="v_sidebarBlocks.relatedProducts"
> contentvariable="relatedProducts"/>
>       <do action="m_products.getRecentlyViewedProducts"/>
>       <do action="v_sidebarBlocks.recentlyViewedProducts"
> contentvariable="recentlyViewedProducts"/>
> </fuseaction>
>
> You have one place to look to see what is happening, or to start 
> making changes. And this is as complicated as it gets...using an MVC 
> approach and creating multiple components to be used in the final 
> output.  And this is only one approach...you don't HAVE to do it like 
> this, but I personally think it's a pretty useful way to go about 
> building a page for the user.
>
> Naturally there are ways to do this without Fusebox, but with FB4 it's

> all at your fingertips, all you need to do is add the 
> "contentvariable" attribute to your <do> tag.
>
> Hopefully this example gets your wheels turning.  But on the other 
> hand, it might seem too complicated if you aren't familiar with 
> Fusebox.  Again, I would invite you to take a look at it for yourself 
> and make judgements based on that.  If you do, please don't hesitate 
> to ask the Fusebox community any questions you might come up with.
>
> Regards,
>
> Brian
>
> 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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

Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. 
http://www.fusionauthority.com/ads.cfm

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

Reply via email to