So far I can't really see the difference but here's a little more
detailed info so that maybe someone can tell me what might be best for
my specific scenario.

We have different types of products, and each needs to be displayed
differently. So here's what I came up with as far as db structure at
this point.

tblTypes
------------
TypeID
TypeName
TypeDesc (Actual CFML to display product details)

Product detail page:

<CFIF TypeID = 0>
Use Default Layout
<CFELSEIF TypeID = 1>
Use Layout 1
<CFELSEIF TypeID = 2>
Use Layout 2
</CFIF>

HTH - thanks for your help,

Donna

On Thu, 7 Oct 2004 10:04:52 -0700, Ian Skinner
<[EMAIL PROTECTED]> wrote:
> Donna
>
> ��� I think that's enough for you to understand what I mean. The #TypeID#
> > and #Layout# will come from a table that could have an unlimited
> > number of results, so I'd like to use the option best for dynamic
> > results.
>
> For the example you provided, both your cfif/cfifelse/cfelse block and a
> cfswitch/cfcase block would for all practical purposes be the same.  
>
> But they would both fall short on a requirement I read in your above quote.
> They both would require one to know what all the possible values of
> TypeID/Layout could be ahead of time, but you indicated that there could be
> an unlimited number of results.  It would not really be possible to have an
> "unlimited" number of branches in either at cfif/cfifelse/cfelse or a
> cfswitch/cfcase structure.
>
> Without knowing more about your application's requirements and logic I can't
> give much advice.  But I suspect I would probably build something that
> simply called a version of "layout" based on the value of "typeID," possible
> a structure {layout[typeID]} or something like that.
>
> --------------
> Ian Skinner
> Web Programmer
> BloodSource
> www.BloodSource.org
> Sacramento, CA
>
> "C code. C code run. Run code run. Please!"
> - Cynthia Dunning
>
> Confidentiality Notice:  This message including any
> attachments is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the
> intended recipient, please contact the sender and
> delete any copies of this message.________________________________
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to