Jamie,

Think of FuseQ as a pre-FB4 proof of concept framework. Fusebox 4 is built
by the same guy (and with lots of community involvement) using the
experience and lessons learned from FuseQ. It is a superior and, IMHO,
better long term solution than FuseQ.

It took me about half a day (your mileage may vary) to become comfortable
moving around in the FB4 framework. There are some basic differences in the
way that you define and architect your FB4 app vs. an FB3 app, but in a few
hours you'll be up to speed and ready to start work. 

Right now, the biggest problem with FB4 is the lack of instructional
documentation. The only way, right now, to learn it is to download the
sample applications and pick them apart. I expect this to change in the next
few months, but it shouldnt stop you from getting started now.

I've been building Fusebox apps since version 1, skipped to and now version
3. Im quite pleased with the direction that FB4 has taken and John Q and the
other contributors have done a fabulous job. I've always built my FB3 apps
to avoid <cfmoduling... back to the app and now that I can <do> any
fuseaction of any circuit when I want to... wow, the doors have swung open.
MVC, no problem. Converting a FuseQ or an FB3 app to FB4 shouldnt be too
terribly difficult... the act and dsp files shouldnt need to change too
much, if at all. You'll just spend a little time hooking them all together
within the new framework.

In a nutshell, don't waste time with FuseQ. It was a cool concept that
matured into FB4. 
http://beta.fusebox.org/.

Jeremy Ridout


-----Original Message-----
From: Jamie Jackson [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2003 11:12 AM
To: CF-Talk
Subject: Re: FuseQ Documentation?


On Wed, 16 Jul 2003 07:53:17 -0400, in cf-talk you wrote:

>The architecture is different, so if you want to link you do have to
>rewrite.  Depending on whether you separated the architecture out of your
>fuses, you might or might not have to rewrite your fuses, but you will have
>to rewrite your switches.

The reason I wanted to know about FuseQ is I've got a FB3 site under
development, and it's done in the MVC sort of way, with a Model, View,
and Controller directory, and things are separated that way. If I try
to keep it pretty strictly MVC, where circuits can't call other
circuits directly, but by way of the Controller, I run into recursive
<cfmodule> calls, which is miserable in stock FB3. This is what I
thought FuseQ was made for.

Our architect is quite reluctant to convert from FB3 to FB4 (which I
understand), but would probably allow FuseQ.

When I had two cfmodules in a row, in a switch, FuseQ worked
brilliantly, with its AddToQ() function. However, when I got to
*recursive* calls, it started dying. Can somebody tell me if there is
a solution to that problem using FuseQ (there must be!)? Does it have
to do with the StartOfQ() function (which I can't find documentation
for)?

I realize this is nobody's problem but my own, but the project is
suffering, and there's got to be a way to do this that won't require
me to teach myself and the entire team FB4, and do a big rewrite. It
seems FuseQ is the answer (even though it's unsupported), and I bet
there's an easy way to do it, but I'm not finding the answer. Anybody
have it? :O

Thanks,
Jamie

>If your fuses will stay the same moving from FB3 to FuseQ, then they will
>stay the same moving from FB3 to FB4.  Again, you will rewrite your
>switches.
>
>The bigger problem will be breaking out of the Nested Layout model.  FB4
>doesn't support Nested Layouts natively (and a good thing too).  I wrote a
>plugin which will support Nested Layouts for moving old apps in,but it
still
>involves a bit of a rewrite.  While FuseQ does support Nested Layouts, it
>also gives you the same control with layouts as FB4 (contentvariables), the
>ability to capture discrete bits of display into variables and then output
>them specifically in their own layout.  
>
>See my presentation from CFUN03 on my site for more info.
>http://www.shayna.com go to the presentations area.
>
>-----Original Message-----
>From: Kola Oyedeji [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, July 16, 2003 7:43 AM
>To: CF-Talk
>Subject: RE: FuseQ Documentation?
>
>
>Sandy
>
>>> 
>>> So why rewrite the application in FuseQ?  FuseQ will not be supported
>>> from
>>> this point forward as all of it is now available in Fusebox 4.  If
>you
>>> are
>>> going to rewrite your application from FB3 to something anyways (and
>>> believe
>>> me to take advantage of content variables and the ability to link
>>> fuseactions together you do have to do a rewrite),
>
>
>I wasn't aware that to take advantage of the chaining fuseactions
>together 
>It would involve a lot more of a re-write. I wrongly had the impression
>from what little I have read on FuseQ that you could plug in the core
>file and start chaining fuseaction together.
>
>
> why not just do it in
>>> FB4?  If you have MX a stable core is available now at
>beta.fusebox.org.
>>> If
>>> you have 5, go ahead and play with FuseQ, but know you will move it
>to
>>> FB4
>>> as soon as the 5 core becomes available.
>
>Maybe. We'll see.
>Thanks anyway.
>
>Kola
> 
>
>
>

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