On Thu, Jul 14, 2011 at 01:53:17AM -0500, TreKing wrote:
On Wed, Jul 13, 2011 at 6:16 PM, Jim Graham<[email protected]> wrote:
First, I think that's asking for trouble. If this data is related it
should be in some common object or structure.
I started off heading that way, using SQLite. I was advised here, and
not much later followed said advice, to use XML instead. What took me
literally a few lines of code in Tcl, to open the database, query the
database, and print the results, started to take multiple screens of
Java code. Once this started, I KNEW I was doing something seriously
wrong on the Java side, and abandoned that and went with the advice I'd
gotten here.
Maybe - I, for one, am not really following. An ExpandableList has a
Parent->List<Children> type relationship. So if I'm following your
example, you'd have a list of brands as the top level list, then within
each of those *each* would have a list of grains, or whatever the
"children" are.
Thanks---that answered the question I was asking---what the docs in the
developer's guide and the examples in the API demos left me wondering
about.
I think you'd have a maintenance headache if you start doing some kind
of crazy indexing into a giant array to determine the sub-lists.
And normally, I'd agree, but with Tcl code being the original source,
it's a simple matter of letting a Tcl script grab the data, and then
split it out into the appropriate structure(s), first into their own
files, and then while editing strings.xml, just do a quick ":r foo"
for each of the resulting files and that's it...done. The data could
either be in a SQLite database or in a structured Tcl script, where each
line would call a proc[1], where the args would be the data for each list.
In fact, as long as the data is in a standard format, it's trivial to
write a script to "read" it. For JStrack, I was still a relative
beginner with Tcl (ca. 1996) when I wrote the script that "reads"
the NHC's FORECAST/ADVISORY (aka Marine Forecast) product and extracts
the data for JStrack's use. To this day, the only significant changes
to that script have been to make it recognize storm types that weren't
in there (extratropical storm, subtropical storm, etc.). That file,
(read_fc.tcl), including lots of LONG blocks of comments, blank lines,
etc., is 358 lines long (according to a quick wc -l). Given what I know
now, I could probably cut that in half...but as the old saying goes,
poor grammar and all, "don't fix it if it ain't broke". :-)
So no, in this case, re-formatting the data, re-structuring it, etc.,
is not an issue. Nor is keeping it maintained. Just a couple of days
ago, I nearly doubled the size of the data, from about 162 entries to
286. It took FAR longer to do the research (hunting is more like it)
to find the data for the "new" malting companies, and then find their
typical analysis data, than the few minutes it took to add it all to
the master list. :-)
Thanks for the info,
--jim
[1] The script that sorts the data out looks something like this:
# run these bits before the procedure to open files, etc.
set nf [open namesfile.xml w] ;# repeat for other data, merge later
puts $nf<string-array name="nameslist"> ;# again, repeat...
set allf [list $nf $v1f $v2f] ;# except with more readable var names
# the actual proc, obviously, has more args.... In this short
# example, iv value2 is not specified, it's an empty string.
proc addfoo {name value1 {value2 ""}} {
puts $nf "<item>$name</item>"
puts $v1f "<item>$value1</item>"
puts $v2f "<item>$value2</item>"
# and so on.....
}
# run after the script to close the files
foreach f $allf { puts $f</string-array> ; close $f }
# If I wanted to, from here, I could append all of these to
# strings.tcl from this script. I do that manually, though.
