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/[email protected]/
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/[email protected]/
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.
