Bandwidth is bandwidth, and that translates to cash any way you look at it.
I doubt anyone has designed a framework with reduction of whitespace in
mind, but it is important.  Nothing like having to scroll through a couple
hundred blank lines to get to the HTML when you're trying to fix some output
issue.

While a lot of whitespace is caused by developers not using CFSILENT and
CFSETTING CFOUTPUTONLY="true" appropriately, the framework can make that
harder.  For example, in FB3 (I'm not sure about FB4), the core files have
CFOUTPUTONLY="true" surrounding them, but every include is surrounded with
CFOUTPUT tags so that the setting doesn't carry to the application code.
Not being able to disable that is a bit of a pain.  Not going to make me
stop using FB, but it does cause a slight annoyance.

Couple corrections for your table:

- FB4 integrates nicely with CFCs, but they are optional.
- FB4 requries a CFAPPLICATION tag, and uses application variables, but
doesn't require a Application.cfm (CFAPPLICATION is generally better placed
in index.cfm)
- FB4 doesn't have any predesignated templates aside from the core files.
The XML files have fixed names (which can be .xml or .xml.cfm, you only list
the latter, btw), but there are no code files that have fixed names.
- FB4 allows CFFLUSH, as long as you're not using contentVariables, which
necessarily use CFSAVECONTENT.  The two different mechanisms can be mixed,
though assuming that a given fuse is not going to be called from a
contentVariabled action is a break in encapsulation, so it should be used
with caution.

One thing that might be interesting to add is something about the
precompilation that FB4 provides, significantly reducing the runtime cost of
the framework, without any of the complexity that caching brings to the
table.  It has a downside, development execution is slower, but that can be
greatly alleviated with some cleverness (encapsulated in a single fuse that
I'd be happy to share, if anyone's interested) and the fusebox.xxx URL
variables.

Cheers,
barneyb

> -----Original Message-----
> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 02, 2004 2:42 PM
> To: CF-Talk
> Subject: white-space - is this a big issue?
>
> Hi all,
>
> Someone recently asked me about adding an item regarding white-space
> to my frameworks comparison matrix at:
>
> http://www.turnkey.to/ontap/docs/index.cfm?doc=articles&article=001
>
> Afaik all of the available frameworks add a fair amount of whitespace
> to a given document, so I'm not sure if the choice of framework is
> really likely to affect download rates (unless the choice is "no
> framework").
>
> I wanted to ask the community at large if they think whitespace is a
> large enough issue that it deserves to be addressed in a comparison of
> frameworks?
>
> My thinking is that at 1.2mbps even a few KB's of extra white space
> isn't going to add more than a fraction of a second to the download is
> it?
>
> Or is the formatting of the resultant html important enough to
> developers to make white-space an important development issue
> regardless of performance?
>
> Thanks,
>
>
> s. isaac dealey     954.927.5117
>
> new epoch : isn't it time for a change?
>
> add features without fixtures with
> the onTap open source framework
> http://www.sys-con.com/story/?storyid=44477&DE=1
>
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to