Bulk transaction mover (was: question about importing .qif files)
Wed, 26 Jul 2000 09:06:06 -0500
> > 2. Which of those "walks" are worthy of trying to build a GUI
> > in order to make them usable to non-Scheme-gurus?
> Since I don't know scheme (and only know enough lisp
> to tweak my .emacs), this is what I would like to see.
> Feel free to comment, argue, flame, whatever...
> [any] [all] [more] [fewer]
> [field1] [match1] [criteria1]
> [field2] [match2] [criteria2]
> [action] [option] [...]
> Fields are "memo", "amount", "payee", etc.
> Matches are "contains", "doesn't contain", "begins with",
> "ends with", maybe "matches glob", and "matches regexp"
> Criteria is free form text to match against.
> Any triggers a "hit" on boolean or of criteria
> All triggers a "hit" on boolean and of criteria
> More adds another line of criteria (or action) to the list
> Fewer removes a line of criteria from the list
> Possible actions are:
> "select matching transactions"
> "set field" with options "memo", "payee", etc.
> "delete transaction" (no options)
> For example, on my credit card QIF, I'd like to:
> Query: MEMO STARTS-WITH [PETSMART]
> Action: SET-FIELD CATEGORY Pets
> Action: SET-FIELD PAYEE Petsmart
That represents a _third_ way that I hadn't thought of, namely of having a
simple user-oriented "query language" that might then be transformed into an
update query. I was sort of assuming that the goal was to have a GUI as the
primary way of activating these "filters," but this is surely a reasonable
alternative that may even be easy to work with to create a GUI.
[Aside: Bill, I agree with you that it would be appropriate to use the Query
API to specify how to "walk" the transactions.]
One concern here is that this moves this towards being almost like SQL, and if
we're creating _almost SQL_, it may make more sense to just plain use SQL.
But I digress, and don't have time for that today...
email@example.com - <http://www.hex.net/~cbbrowne/lsf.html>
You shouldn't anthropomorphize computers; they don't like it.