Hi Bruce - no problem for the mail, I'm just glad it helped clear a few
things up. The general rule I use to decide whether or not to build the
content as a big string and then dump it either incrementally or at the
end is a bit rough but basically:

If the template/custom tag is primarily a data processing tag with little
output, build the string.

If the template/custom tag is primarily an output tag with little data
processing then just write the output directly.

For anything in between I break the page down into chunks where each
major chunk is either data or output and apply the rule that way. When
it's easier just to write out the content directly I'll maybe manually
remove some of the white space between tags so I have longer lines of
harder-to-read code but when it's only a CFSET or two, sometimes the
ease justifies it. For more complex code though I would never do that.
It's a question of balancing how legible your code is against the
quality of the HTML generated.

Another useful tag (albeit hardly used I would bet) is
CFPROCESSINGDIRECTIVE.
You can use this tag to suppress additional white space generated by CFML
and I think if you were to turn this on before you go into your CFLOOP,
it would help a great deal. This is actually one of those tags that I
would be inclined to back you on your comments about the lang ref :) It's
worth trying the tag in a few different places to see how to use it since
the manual is a bit vague on it but it _is_ useful.

If you have access to your CF Administration, ensure that "Suppress
white space by default" is enabled as this seems to save you some work.

A final suggestion on the example you gave below would be to replace
your blocks of CFSETs with CFSCRIPTs. There's a general consensus that
3 or more CFSETs in a row will be faster as a block of assignments in
a CFSCRIPT block, i.e. if you replace:

<cfset PrevUpdateType = 0>
<cfset subHeaderLine = "">
<cfset CurVID = qGetUserAgents.vid>
<cfset ProcAMIDList = "">

with

<cfscript>
PrevUpdateType = 0;
subHeaderLine = "";
CurVID = qGetUserAgents.vid;
ProcAMIDList = "";
</cfscript>

You should see a performance gain. Of course for 4 CFSETs you're not really
going to see a 10ms gain in isolation but in the long term, and more so as
the number of assignments scales up, you will see a benefit.

What you might not realise though is that any code within a CFSCRIPT block
produces no white space! So the code above written as

<cfscript>
PrevUpdateType = 0;


subHeaderLine = "";


CurVID = qGetUserAgents.vid;


ProcAMIDList = "";
</cfscript>

would look exactly the same as the code above when viewed in the HTML source
produced! I'm one of those people who loves CFSCRIPT (a load of people love
it, a load of people hate it) and unless I'm performing a single CFSET,
I use it all the time since the syntax is much cleaner, especially for
struct operations and functions that return no value.

In fact, looking at the code you posted again, you could replace all of
it by a CFSCRIPT switch block, using WriteOutput() to render the document
headers, i.e.

<cfloop index="CurAMID" list=#stUserAMIDs[vid]#>
<cfscript>
// Check if the type changed...time to put up a new sub-header label if so
if( stAMIDdocUType[CurAMID] neq PrevUpdateType )
{
        switch( stAMIDdocUType[CurAMID] )
        {
                case "1":
                {
                        WriteOutput( '<strong>New Documents:</strong><br>' );
                        subHeaderLine = cr
                                & "New Information (placed on the website since "
                                & Dateformat(LastReportDate, 'mmm dd, yyyy')
                                & " 12:00am):";
                        SummaryLabel = "Description: ";
                        break;
                }

                case "2":
                {
                        WriteOutput( '<strong>Modified Documents:</strong><br>' );
                        subHeaderLine = cr
                                & "Modified Information (since "
                                & Dateformat(LastReportDate, 'mmm dd, yyyy')
                                & " 12:00am):";
                        SummaryLabel = "Modifications: ";
                        break;
                }
        }
}

// Construct the email message body for TEXT email msg and store
// it in a structure indexed by VID
// ... etc. ...
<cfscript>

> As for my comments about the Language Ref Manual...
> The CFSILENT tag is one example.  You gave me more info that the book
> and it's important info.

No problem ;)

Another place to read for useful function info is the release notes.
4.5.1 SP-2 introduced a few new struct functions which are just sooo
useful. It looks like they were added to implement a few of Spectra's
slower custom tags as C++ functions, but whatever the reason, StructSort
and StructKeyFind are just too handy.

For a lang ref which hopefully has more of the info you need try getting
the CF5 docs from the Allaire site unless you're already using CF5 of
course.
I've not had a chance to really jump into 5 since the beta program but the
core functions are largely the same so hopefully the docs will have been
updated.

> For another example, take a look at the CreateODBCDateTime function.  It
> says "Returns a date/time object in ODBC timestamp format."  Wow, I could
> have figured that out from the title of the function.  But what is ODBC
> timestamp format?  When should I use it?

ODBC timestamp format, as far as I know, is just a standardised format for
entering date/time data into a database via an ODBC connection. It just
ensures that no matter what locale the date is coming from, or what time
zone the date is entered from, it always gets entered in the same way. As
an example, {ts '2001-09-24 16:03:45'}, which shows the format to be
{ts 'yyyy-MM-dd hh:mm:ss'}.

We used to use CreateODBCDateTime() when we worked with Access but have
stopped using it for SQL Server, even though we still use an ODBC connection
(SQL7 and OLEDB was a huge nightmare for us). I think the reason that we
no longer have to use it is because we are using stored procedures for
almost all of our SQL7 work which are among the greatest things to ever
grace database development. I'm guessing that CFPROCPARAM automatically
formats the date type accordingly.

Anyway, must get back to work but let me know if I can be any more help,

Colin

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get the mailserver that powers this list at http://www.coolfusion.com
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to