On Thu, 06 Apr 2000 16:22:43 MDT, the world broke into rejoicing as
Bryan Larsen <[EMAIL PROTECTED]>  said:
> What I really want is a way to save views into reports.  For example,
> I want a user defined report that gives me my budget status for the last
> 30 days, a report that gives me the "balance" report for the current year,
> et cetera.

That mandates having some sort of data structure to represent "queries,"
perhaps some sort of oversimplified variation on SQL.

Actually, not...  

If this stuff is to be stored, it needs *not* to be a language, but
rather to have some sort of "ID/Key" structure.

SAP R/3 has *exactly* this idea, with something known as "variants,"
which are the arguments that you pass in to reports.  Variants can be
stored and recalled.  They're rather ugly to manage in R/3; I suspect
we can do better.

What this requires is that each of the arguments in a given report
has several things defined:

a) The argument needs to have a "type."  Perhaps a date, or a range of
dates.  Or a string value.  Or a range thereof.  Or a list of values.
Anyhoo.  TYPE.  (make-arg-record 'type 'date)

b) The argument needs to have a NAME, so that it has identity.
We have a date range with:
   (make-arg-record 'type 'date 'name "Effective Dates")

c) The argument needs to have value associated with it.   Perhaps
like the following:

   (make-arg-record 'type 'date 'name "Effective Dates"
        'value '((or
                  (and
                   (in "1999/01/01" "2000/02/02")  
                   (not "1999/07/08"))
                 (before "1997/03/02"))))
        Which I will admit would be frightening to actually *use.*
        And the date should be in the "native" GnuCash format...

Or how about:
  (make-arg-record 'type 'string 'name "Account"
        'value (regexp "*Income*"))

I'm suggesting a rather zowie representation of the value not so much
with the expectation of seeing it implemented tomorrow as because:
a) R/3 *does* offer some rather flexible options, and that seems a useful
   idea (I found it useful at work *today*), and
b) if it gets pigeonholed to *not* be flexible, we might get stuck
   with a too-weak implementation that will be too entrenched to
   consider future improvements...

Reality may wind up a bit more pedestrian, but start by thinking
powerful...
--
"In other words  -- and this is the rock solid  principle on which the
whole  of the Corporation's  Galaxy-wide success  is founded  -- their
fundamental design  flaws are  completely hidden by  their superficial
design flaws." -- HHGTG
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/framewrk.html>

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]


Reply via email to