Jeremy you are wrong, see my reply to Dave regarding dynamic frames.
----- Original Message -----
From: "Jeremy Allen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 10:50 AM
Subject: RE: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox )
> Can I second that?
>
> We do work on a largish FuseBox app and I had to write a
> chat client (scary using HTTP in and of itself) and..
> most of the pages including the header and footer is
> overhead not only that it just made it silly so now
> chat is a bastard child of sorts that skirts around
> several things such as headers and footers of
> the rest of the app.
>
> One frame submits another which rewrites another frame.
> Fusebox was *not* up to that sort of thing really. It
> is much easier to totally seperate the logic processing
> (Grabbing messaging updating message tables updating users
> etc. etc) into a totally seperate 'layer' of the app.
>
> And then just have another layer that 'rewrites' the
> actual display or presentation.
>
> One of the reasons CF/ASP/whatever code is so darned ugly
> is some of the time you just have to mix presentation with
> logic (often), and some of the time core components of your
> logic.
>
> Fusebox helps in this area, but only some of the way, it
> is my personal belief it can some of the time obfusticate
> this goal somewhat, You cant always have your cake and
> eat it too :)
>
> Jeremy Allen
> [EMAIL PROTECTED]
> -----Original Message-----
> From: Dick Applebaum [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 19, 2000 12:54 PM
> To: [EMAIL PROTECTED]
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: [CF-Talk] RE: Ben Forta, I call on thee (was: What is
> Fusebox )
>
>
> At 10:39 AM -0400 9/19/00, Dave Watts wrote:
> >
> >At Fig Leaf, our goals are not to build CF-centric applications, but
n-tier
> >applications. We partition application logic between the application
server
> >(CF), the database, the client, and potentially object tiers between the
> >application server and the database. Fusebox doesn't address how to
manage
> >that complexity, so it doesn't work for us from that approach.
> >
> >We provide complex client interfaces, using frames, JavaScript, Dynamic
> HTML
> >and Flash. It's not uncommon for our applications to have one frame
> >dynamically generating the contents of another. Fusebox, with its header
> and
> >footer files, is spectacularly unsuited to this.
> >
>
> I agree totally with the above!. I tend to use a lot of frames and
> client_side programming to reduce bandwith and improve the user
> experience. To accomplish this, you need to distribute much of the
> programming logic for navigation/validation and what I call
> application "lubricant" or "glue" to the client.
>
> Another technique I like to use is to combine the logic to:
>
> present a form
> validate a form
> Re-present a form in error ( with a popup explaining all errors
> Present the response to an Accepted form
>
> in a separate program module/template... it is a lot easier to
> delegate the entire process to a separate module, rather than
> distribute it among separate modules navigated by index.cfm
>
> There are times where you must invoke external operations (Cybercash,
> CFHTTP harvesting, etc). These operations can timeout (no response)
> or return an error.
>
> When this happens, you need to retry a given number of times, then
> try an alternate route.
>
> At each of these stages, you could get another, possibly different, error.
>
> Example from an early CyberCash/CashRegister implementation:
>
> Attempt 1: Cybercash - Authorization Times out (No response)
> Attempt 2: Cybercash - Authorization declined - already posted
> Attempt 3: CFHTTP CashRegister - Request Posted Item Info Times out
> Attempt 4: .......
>
> To try to do this with separate modules invoked through a an index.cfm
> "traffic cop" unnecessarily complicates the process.
>
> HTH
>
> Dick
>
>
>
>
>
>
>
>
> --------------------------------------------------------------------------
--
> --
> Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
>
> --------------------------------------------------------------------------
----
> Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
> To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
>
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
