RE: BIG Forms: CFSWITCH or CFIF?
Thanks to Isaac, Matt and Barney for giving me stuff to think about. I'd clean forgot about qforms and terraforms, and using a custom tag never occurred to me. Since I have to do this now and my 6.1 upgrade won't happen for at least a month I can't use udf's on this project, unfortunately.While my 4.5 box is wonderfully stable I've about had it with all of the can'ts that go with the older technology. Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc.http://mysecretbase.com [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: BIG Forms: CFSWITCH or CFIF?
Method 2 for sure.At the Java level, both the CFIF and the CFSWITCH are both if statements, because the Java switch statement only works on numeric types (byte, short, int, long and char).Then, factor in the extra assignment overhead on method 1, count the number of extra lines in method 1, and then the vastly superior readability of method 2, and I think it's a pretty clear-cut case.At least in my mind.;) IMHO, 99.9% of the time, readable, easily maintainable code is way more valuable than speed.If we're talking about the last fractions of a percent of performace, than it's almost never worth it.Better to spend 10 minutes optimizing some query, since that might actually result in several milliseconds of speed. Cheers, barneyb -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 1:58 PM To: CF-Talk Subject: BIG Forms: CFSWITCH or CFIF? I'm going over old code that has pre-filled form fields based on previous user entry.Many are select boxes or radio groups with lots of options.The current coding method is shown in Method 1 below.The common way I see recommended to do this is in Method 2.Before I rewrite this code, I thought I'd ask which y'all think is the better approach for a big form. Method 1 is verbose, but its use of cfswitch might be faster? Method 2 is easier to code, but uses slower cfifs.Lots of them on longer forms. So on a form with a couple of dozen fields like this, which do you think is faster/a better approach? !---METHOD 1--- cfparam name=variables.LocalAA01 default= type=string cfparam name=variables.LocalAA02 default= type=string cfswitch _expression_=#QName.AA# cfcase value=A cfset variables.LocalAA01= selected /cfcase cfcase value=B cfset variables.LocalAA02= selected /cfcase cfdefaultcase cfset variables.LocalAA01= selected /cfdefaultcase /cfswitch SELECT name=AA OPTION value=A#variables.LocalAA01#Choice A OPTION value=B#variables.LocalAA02#Choice B /SELECT !---METHOD 2--- SELECT name=AA OPTION value=Acfif not CompareNoCase(QName.AA,A) selected/cfifChoice A OPTION value=Bcfif not CompareNoCase(QName.AA,B) selected/cfifChoice B /SELECT -- --- Matt Robertson,[EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com --- -- [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: BIG Forms: CFSWITCH or CFIF?
Barney Boisvert wrote: Method 2 for sure.At the Java level, both the CFIF and the CFSWITCH are both if statements Very Interesting.I'm still running on CF 4.5 but I'll be upgrading to 6.1 shoertly. IMHO, 99.9% of the time, readable, easily maintainable code is way more valuable than speed Absolutely.I've got about 50 of these forms, and some of them have up to 250 lines of this stuff at page top.On the other side, though,is this is part of a very complex insurance rating system, where the execution time for the process at hand is about 3000 (three thousand) ms.At that scale I'm really conscious of exec times. -- Original Message -- From: Barney Boisvert [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date:Tue, 16 Dec 2003 14:05:33 -0800 Method 2 for sure.At the Java level, both the CFIF and the CFSWITCH are both if statements, because the Java switch statement only works on numeric types (byte, short, int, long and char).Then, factor in the extra assignment overhead on method 1, count the number of extra lines in method 1, and then the vastly superior readability of method 2, and I think it's a pretty clear-cut case.At least in my mind.;) IMHO, 99.9% of the time, readable, easily maintainable code is way more valuable than speed.If we're talking about the last fractions of a percent of performace, than it's almost never worth it.Better to spend 10 minutes optimizing some query, since that might actually result in several milliseconds of speed. Cheers, barneyb -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 1:58 PM To: CF-Talk Subject: BIG Forms: CFSWITCH or CFIF? I'm going over old code that has pre-filled form fields based on previous user entry.Many are select boxes or radio groups with lots of options.The current coding method is shown in Method 1 below.The common way I see recommended to do this is in Method 2.Before I rewrite this code, I thought I'd ask which y'all think is the better approach for a big form. Method 1 is verbose, but its use of cfswitch might be faster? Method 2 is easier to code, but uses slower cfifs.Lots of them on longer forms. So on a form with a couple of dozen fields like this, which do you think is faster/a better approach? !---METHOD 1--- cfparam name=variables.LocalAA01 default= type=string cfparam name=variables.LocalAA02 default= type=string cfswitch _expression_=#QName.AA# cfcase value=A cfset variables.LocalAA01= selected /cfcase cfcase value=B cfset variables.LocalAA02= selected /cfcase cfdefaultcase cfset variables.LocalAA01= selected /cfdefaultcase /cfswitch SELECT name=AA OPTION value=A#variables.LocalAA01#Choice A OPTION value=B#variables.LocalAA02#Choice B /SELECT !---METHOD 2--- SELECT name=AA OPTION value=Acfif not CompareNoCase(QName.AA,A) selected/cfifChoice A OPTION value=Bcfif not CompareNoCase(QName.AA,B) selected/cfifChoice B /SELECT -- --- Matt Robertson,[EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com --- -- [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: BIG Forms: CFSWITCH or CFIF?
Personally I'd recommend neither ...
I doubt the cfswitch will save you any processing speed in this
particular case. However, I'd go for a function or custom tag to
handle your form elements and pass a structure to them to populate the
individual fields. Inside the tag, check the structure for the
appropriate key and use it if available to populate the field -- this
will cut down on your typing and improve consistency within the
application at the expense of a little processing time.
Matthew Walker produces a really nice form management tool that does
this ... I don't remember what he charges for it, but I'm sure he'd be
willing to discuss licensing for inclusion in other apps if you're
wanting to sell something.
Otherwise there's also the qForms _javascript_ API which is open-source
and pretty good in comparison to a lot of other OS projects that tend
to be tough to work with. http://www.pengoworks.com ... Once you've
got it installed in your app, then you can populate your whole form
with something like this:
cfloop index=x list=#qname.columnlist#
cfparam name=form.#x# default=#qname[x][1]#/cfloop
script type=_javascript_
function temp() {
cfwddx action="" input=#form# toplevelvariable=myValues
myForm = new qForm(myformname);
myForm.setFields(myValues);
} window.>
/script
This cuts down all that cfif or cfswitch stuff... The onTap framework
now has a qForms library that makes this even easier, though I
scarcely see you plugging an existing app into the framework. :) In
any event, with the qForms library in an onTap application this whole
8 or so lines of code here can be condensed to one or two calls to a
UDF.
I'm going over old code that has pre-filled form fields
based on previous user entry.Many are select boxes or
radio groups with lots of options.The current coding
method is shown in Method 1 below.The common way I see
recommended to do this is in Method 2.Before I rewrite
this code, I thought I'd ask which y'all think is the
better approach for a big form.
Method 1 is verbose, but its use of cfswitch might be
faster?
Method 2 is easier to code, but uses slower cfifs.Lots
of them on longer forms.
So on a form with a couple of dozen fields like this,
which do you think is faster/a better approach?
!---METHOD 1---
cfparam name=variables.LocalAA01 default=
type=string
cfparam name=variables.LocalAA02 default=
type=string
cfswitch _expression_=#QName.AA#
cfcase value=A
cfset variables.LocalAA01= selected
/cfcase
cfcase value=B
cfset variables.LocalAA02= selected
/cfcase
cfdefaultcase
cfset variables.LocalAA01= selected
/cfdefaultcase
/cfswitch
SELECT name=AA
OPTION value=A#variables.LocalAA01#Choice A
OPTION value=B#variables.LocalAA02#Choice B
/SELECT
!---METHOD 2---
SELECT name=AA
OPTION value=Acfif not CompareNoCase(QName.AA,A)
selected/cfifChoice A
OPTION value=Bcfif not CompareNoCase(QName.AA,B)
selected/cfifChoice B
/SELECT
--
---
Matt Robertson,[EMAIL PROTECTED]
MSB Designs, Inc. http://mysecretbase.com
---
--
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
RE: BIG Forms: CFSWITCH or CFIF?
RE form management tool: http://www.electricsheep.co.nz/terraform/ if you
want to have a look. But it doesn't run on 4.5 as it relies heavily on UDFs.
Also you would basically need to rewrite your form. One advantage would be
that the resulting form is much more readable. Here's how I'd make yours
more readable:
cfset options = A,B
SELECT name=AA
cfoutput
cfloop list=#options# index=option
OPTION value=#option# cfif not
CompareNoCase(QName.AA,option) selected/cfifChoice #option#/option
/cfloop
/cfoutput
/SELECT
This doesn't look better, but you could make a custom tag:
cfparam name=attributes.options
cfparam name=attributes.value
cfparam name=attributes.field
cfoutput
SELECT name=#attributes.field#
cfloop list=# attributes.options# index=option
OPTION value=#option# cfif not
CompareNoCase(attributes.value,option) selected/cfifChoice
#option#/option
/cfloop
/SELECT
/cfoutput
I guess you were asking about speed. The sad fact is that the fastest code
is often the ugliest and least elegant, and least maintainable -- the
fastest code is the code that is most similar to a static page. However the
speed gain is likely to be miniscule. To me both those code examples look
bad and I wouldn't want to be maintaining that code.
-Original Message-
From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 17 December 2003 3:21 p.m.
To: CF-Talk
Subject: Re: BIG Forms: CFSWITCH or CFIF?
Personally I'd recommend neither ...
I doubt the cfswitch will save you any processing speed in this
particular case. However, I'd go for a function or custom tag to
handle your form elements and pass a structure to them to populate the
individual fields. Inside the tag, check the structure for the
appropriate key and use it if available to populate the field -- this
will cut down on your typing and improve consistency within the
application at the expense of a little processing time.
Matthew Walker produces a really nice form management tool that does
this ... I don't remember what he charges for it, but I'm sure he'd be
willing to discuss licensing for inclusion in other apps if you're
wanting to sell something.
Otherwise there's also the qForms _javascript_ API which is open-source
and pretty good in comparison to a lot of other OS projects that tend
to be tough to work with. http://www.pengoworks.com ... Once you've
got it installed in your app, then you can populate your whole form
with something like this:
cfloop index=x list=#qname.columnlist#
cfparam name=form.#x# default=#qname[x][1]#/cfloop
script type=_javascript_
function temp() {
cfwddx action="" input=#form# toplevelvariable=myValues
myForm = new qForm(myformname);
myForm.setFields(myValues);
} window.>
/script
This cuts down all that cfif or cfswitch stuff... The onTap framework
now has a qForms library that makes this even easier, though I
scarcely see you plugging an existing app into the framework. :) In
any event, with the qForms library in an onTap application this whole
8 or so lines of code here can be condensed to one or two calls to a
UDF.
I'm going over old code that has pre-filled form fields
based on previous user entry.Many are select boxes or
radio groups with lots of options.The current coding
method is shown in Method 1 below.The common way I see
recommended to do this is in Method 2.Before I rewrite
this code, I thought I'd ask which y'all think is the
better approach for a big form.
Method 1 is verbose, but its use of cfswitch might be
faster?
Method 2 is easier to code, but uses slower cfifs.Lots
of them on longer forms.
So on a form with a couple of dozen fields like this,
which do you think is faster/a better approach?
!---METHOD 1---
cfparam name=variables.LocalAA01 default=
type=string
cfparam name=variables.LocalAA02 default=
type=string
cfswitch _expression_=#QName.AA#
cfcase value=A
cfset variables.LocalAA01= selected
/cfcase
cfcase value=B
cfset variables.LocalAA02= selected
/cfcase
cfdefaultcase
cfset variables.LocalAA01= selected
/cfdefaultcase
/cfswitch
SELECT name=AA
OPTION value=A#variables.LocalAA01#Choice A
OPTION value=B#variables.LocalAA02#Choice B
/SELECT
!---METHOD 2---
SELECT name=AA
OPTION value=Acfif not CompareNoCase(QName.AA,A)
selected/cfifChoice A
OPTION value=Bcfif not CompareNoCase(QName.AA,B)
selected/cfifChoice B
/SELECT
--
---
Matt Robertson,[EMAIL PROTECTED]
MSB Designs, Inc. http://mysecretbase.com
---
--
_
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
RE: BIG Forms: CFSWITCH or CFIF?
Thanks Matt -- I'd meant to provide a url for terraform and forgot --
I managed to include the one for qForms. :)
RE form management tool:
http://www.electricsheep.co.nz/terraform/ if you
want to have a look. But it doesn't run on 4.5 as it
relies heavily on UDFs.
Also you would basically need to rewrite your form. One
advantage would be
that the resulting form is much more readable. Here's how
I'd make yours
more readable:
cfset options = A,B
SELECT name=AA
cfoutput
cfloop list=#options# index=option
OPTION
value=#option# cfif
not
CompareNoCase(QName.AA,option) selected/cfifChoice
#option#/option
/cfloop
/cfoutput
/SELECT
This doesn't look better, but you could make a custom tag:
cfparam name=attributes.options
cfparam name=attributes.value
cfparam name=attributes.field
cfoutput
SELECT name=#attributes.field#
cfloop list=# attributes.options# index=option
OPTION
value=#option# cfif
not
CompareNoCase(attributes.value,option)
selected/cfifChoice
#option#/option
/cfloop
/SELECT
/cfoutput
I guess you were asking about speed. The sad fact is that
the fastest code
is often the ugliest and least elegant, and least
maintainable -- the
fastest code is the code that is most similar to a static
page. However the
speed gain is likely to be miniscule. To me both those
code examples look
bad and I wouldn't want to be maintaining that code.
-Original Message-
From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 17 December 2003 3:21 p.m.
To: CF-Talk
Subject: Re: BIG Forms: CFSWITCH or CFIF?
Personally I'd recommend neither ...
I doubt the cfswitch will save you any processing speed in
this
particular case. However, I'd go for a function or custom
tag to
handle your form elements and pass a structure to them to
populate the
individual fields. Inside the tag, check the structure for
the
appropriate key and use it if available to populate the
field -- this
will cut down on your typing and improve consistency
within the
application at the expense of a little processing time.
Matthew Walker produces a really nice form management tool
that does
this ... I don't remember what he charges for it, but I'm
sure he'd be
willing to discuss licensing for inclusion in other apps
if you're
wanting to sell something.
Otherwise there's also the qForms _javascript_ API which is
open-source
and pretty good in comparison to a lot of other OS
projects that tend
to be tough to work with. http://www.pengoworks.com ...
Once you've
got it installed in your app, then you can populate your
whole form
with something like this:
cfloop index=x list=#qname.columnlist#
cfparam name=form.#x# default=#qname[x][1]#/cfloop
script type=_javascript_
function temp() {
cfwddx action="" input=#form#
toplevelvariable=myValues
myForm = new qForm(myformname);
myForm.setFields(myValues);
} window.>
/script
This cuts down all that cfif or cfswitch stuff... The
onTap framework
now has a qForms library that makes this even easier,
though I
scarcely see you plugging an existing app into the
framework. :) In
any event, with the qForms library in an onTap application
this whole
8 or so lines of code here can be condensed to one or two
calls to a
UDF.
I'm going over old code that has pre-filled form fields
based on previous user entry.Many are select boxes or
radio groups with lots of options.The current coding
method is shown in Method 1 below.The common way I see
recommended to do this is in Method 2.Before I rewrite
this code, I thought I'd ask which y'all think is the
better approach for a big form.
Method 1 is verbose, but its use of cfswitch might be
faster?
Method 2 is easier to code, but uses slower cfifs.Lots
of them on longer forms.
So on a form with a couple of dozen fields like this,
which do you think is faster/a better approach?
!---METHOD 1---
cfparam name=variables.LocalAA01 default=
type=string
cfparam name=variables.LocalAA02 default=
type=string
cfswitch _expression_=#QName.AA#
cfcase value=A
cfset variables.LocalAA01= selected
/cfcase
cfcase value=B
cfset variables.LocalAA02= selected
/cfcase
cfdefaultcase
cfset variables.LocalAA01= selected
/cfdefaultcase
/cfswitch
SELECT name=AA
OPTION value=A#variables.LocalAA01#Choice A
OPTION value=B#variables.LocalAA02#Choice B
/SELECT
!---METHOD 2---
SELECT name=AA
OPTION value=Acfif not CompareNoCase(QName.AA,A)
selected/cfifChoice A
OPTION value=Bcfif not CompareNoCase(QName.AA,B)
selected/cfifChoice B
/SELECT
--
---
Matt Robertson,[EMAIL PROTECTED]
MSB Designs, Inc. http://mysecretbase.com
---
--
_
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
