Using all of that complex structs n such is more favorable than
just stuffing that stuff in a few tables and querying for a
particular customers configuration information at application
initalization? That takes out at least a level or two of
complexity right there. Leaving you with just the original
struct to query or grab settings from whenever you need
after you initalize it during app startup..
So.. You are querying the database once and then just
grabbing a (relatively) small set of data from memory
to check settings and customize the application. It just
seems a lot more sensible to use the database to do hard
work like that :)
Jeremy Allen
[EMAIL PROTECTED]
[Insert cool title here]
-----Original Message-----
From: Gene Kraybill [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 02, 2000 6:30 AM
To: [EMAIL PROTECTED]
Subject: Complex Arrays and Structures
Looking for some peer review or alternative ideas on the following...
I'm working on a rather complex B2B CF application where we basically want
to have a
single set of code drive different customized "versions" of the application
based on a
whole bunch of config settings. This is for an ordering system that will
meet the varying
needs of, say, 20 large corporate trading partners. Set a bunch
of config options for a certain customer, and the app will show certain
products and
display and process data in a customized way.
The approach we've been working on is to create a large application
structure to hold the
configuration settings for each customer. The key in the first dimension
would be the
customer ID number.
The main config options are numbered, so Customer 1's second config option
(set to
Yes or No) would be referenced in a struct like this:
#Application.Str_ConfigCust["1"]["2"]#
Now we also need to store various other string, array and query data for
quick on-the-fly
access, so we're looking at also storing that at the second dim, such as:
#Application.Str_ConfigCust["1"]["OtherDataArray"]#
#Application.Str_ConfigCust["1"]["SomeSimpleString"]#
#Application.Str_ConfigCust["1"]["SomeQuery"]#
We also need to hold the order form data, and there can be multiple forms,
so I figured
there could be a "Form" struct at the second dimension that holds array data
for each
form.
So
#Application.Str_ConfigCust["3"]["Form"]["2"]["FormItemsArray"][5][8]# would
reference
the form items on row 5, column 8 on Customer 3's Order Form No. 2.
I've never attempted to use arrays, structs and queries to this level of
complexity, or
mix and match them like this in the same structure. The advantage it seems
to offer is
that all config data will be held in a single structure, and it'll be easy
to reference
it by customer number and loop over it when needed. But it's also rather
complex and the
var references are long and unwieldy, so I'm having second thoughts. Also, I
need to
figure out whether storing all this config data in an application structure
will cause
memory problems. None of these arrays or queries are very large, but
still...
Any general comments/ideas/brickbats anyone? And how could we roughly
estimate how much
memory a complex structure like this will require?
Gene Kraybill
LPW & Associates
----------------------------------------------------------------------------
--
Archives: http://www.mail-archive.com/[email protected]/
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/[email protected]/
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.
