Re: definition list recommendations?
Re: definition list recommendations?
- Subject: Re: definition list recommendations?
- From: has <email@hidden>
- Date: Wed, 26 Jan 2005 18:23:09 +0000
David Stevens wrote:
I must admit, I didn't understand all of it, but am willing to try
just assigning them to variables or making a list and a short loop,
and then learning (or investigating)
The basic gist is this: if you have a large amount of fairly regular,
static data, it's much simpler and a lot less work to keep treating
it as *data* compared to converting it all into program code. [1]
In your case you've got 2000 pairs of "xyz"->"blah-blah-blah", which
you want to use as transformations applied to your input files. Now,
you can either write a 2000-line tab-delimited data file and a
twenty-line script that sucks that information in and applies it to
your source files, or you can write a 4000-line script consisting of
a humungus if..elseif... block with all that transformation info
inextricably embedded in it. The question to ask yourself is: which
one of these approaches will be easier?
Here's a couple of considerations to get you started:
- Even from your cut-down example I can see your transformation data
isn't 100% regular, so you might, for example, have to handle your
"r5"s (exact comparisons - very easy to do) separately to your "cd"s
(wildcardish - may be easy, may be hard; depends exactly on their
nature). So it might require a 50-line script instead of a 20-line
one to deal with that extra twist, plus an extra marker in your
tab-delimited data file to indicate which of these ways each
transformation should be applied. And so on. And if it turns out that
there's hardly any kind of regularity to your transformation data at
all, then it probably will be easier just to hand-code it rather than
write some super-intelligent program to figure it all out from some
super-complex transformation data table.
- If all your transformation data can be formatted as a tab-delimited
text file then it will be extremely easy to write up, check, and -
where necessary - modify in future. You could, for example, keep all
that data in an Excel spreadsheet, which'd make it very pleasant and
efficient to work with. You might even write spreadsheet macros that
will go through your columns and run automatic checks to see that all
values have been entered correctly. The script that reads and applies
those transformations will be far simpler and easier to debug too.
Whereas you won't get any of those benefits if everything is all
tangled together as a 4000-line script.
There's bound to be other pros and cons to consider too, but that's
your job. :)
For the inquiring mind, the original code comes from an old DOS page
planning tool, the translator turns it into xtags for QuarkXPress.
I've been assigned the task of evaluating an applescript approach.
If you're doing heavy text processing, you should really consider
other scripting languages too. Perl and Python are much more powerful
and far better suited to this type of task. For example, let's say
you store your key-value data in a tab-delimited file like this:
xy blah blah blah
d5 bling-bling
rtm flog glog blog
To convert this data into a Python dict would take:
import re
f = file('/Your/Path/To/TransformationTable.txt')
tableText = f.read()
f.close()
tableRows = re.compile('^([^\t]+)\t(.*)$', re.M).findall(tableText)
tableDict = dict(tableRows) # {'d5': 'bling-bling', 'rtm':
'flog glog blog', 'xy': 'blah blah blah'}
To get the value for a given key, you'd use:
value = tableDict[key]
You can now go through each line of the file to be processed, looking
up tableDict for the value to translate it to and writing the result
to your output file:
sourceFile = file('/Your/Path/To/SourceFile.txt')
destinationFile = file('/Your/Path/To/SourceFile.txt', 'w')
while 1:
oldLine = sourceFile.readline()
if not key: break # an empty string indicates
end-of-file, so stop when that happens
newLine = tableDict[oldLine.strip('\n')]
destinationFile.write(newLine+ '\n')
sourceFile.close()
destinationFile.close()
Of course, this is a trivial example which only does exact matching,
but should give you some idea of how a data-driven solution might
work.
In Perl the same script would be a third of this length and look like
the cat walked on your keyboard. In AppleScript it might not be much
longer - but ONLY IF you can find libraries or osaxen to do all the
heavy lifting bits for you. Otherwise you're much better off using
another language - 'cos once you run out of osaxen to do all the
dirty work for you, writing such scripts in AppleScript can quickly
turn into very hard work indeed. :(
HTH
has
[1] Unless you're using Lisp - in which case you can't tell the
difference anyhow. ;)
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden