Well As sean wrote, I dont believe headers/footers are actually
a guideline part of Fusebox, I just wrote its own headers to
get around it or did not use them at all and tried to avoid
doing anything other than pure HTML in the header/footer.

So my case is not quite like yours where as I did not need
headers for quite a few things beacuse they were just
redrawing several different frames and the places I did
need a header that most other pages could use was not
acceptable for this particular instance it needed trimmed
down output (chat client) I didnt want it rewriting
anything other than the bare minimum since the bytes would
add up after a few thousand requests so I had to trim it down
and did not want to use and custom tags or anything given how
intensive the chat is (A page request every 8 seconds and
a seperate counter every 60 seconds) So I just plain did not
use them.

So to your actual question, im not sure
<G>


Jeremy Allen
[EMAIL PROTECTED]



-----Original Message-----
From: Peter Theobald [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 19, 2000 3:44 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [CF-Talk] RE: Ben Forta, I call on thee (was: What is
Fusebox )


So please tell us more about the methods you DID use to solve that problem.

I have a site where the "page template" is an HTML file that uses lots of
tables to lay things out all over the page. There are three places where I
will insert the page specific stuff.
I cannot figure out how FuseBox style can do this because I have to INCLUDE
the template, and the template has to INCLUDE the appropriate three parts. I
can't have a "header" a "body" and a "footer" because of the table nesting.
The body is INSIDE the template...


At 01:50 PM 9/19/00 -0400, Jeremy Allen wrote:
>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.


---------------------------------------------------------------------------
Peter Theobald, Chief Technology Officer
LiquidStreaming http://www.liquidstreaming.com
[EMAIL PROTECTED]
Phone 1.212.545.1232 Fax 1.212.679.8032

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

Reply via email to