GncBusiness v. GNCSession

Linas Vepstas linas@linas.org
Sun, 25 Nov 2001 15:52:33 -0600


On Fri, Nov 23, 2001 at 08:28:02PM -0500, Derek Atkins was heard to remark:
> linas@linas.org (Linas Vepstas) writes:
> 
> Could you explain to me how you convert from a glade definition
> and XML schema to, e.g., gncInvoiceGetValue() or gncCustomerGetName()?

Usually, you don't.  If all of your objects are defined at runtime,
its somewhat unusual to have compile-time interfaces to them.  But its
not impossible:

char * 
gncCustomerGetSurname (GNCId *cust_id) 
{
   Obj *obj = get_obj ("Customer");
   if (!obj) return NULL;
   Field *field = get_field (obj, "Surname");
   if (!field) return NULL;

   Query *q = query_new();
   query_search_obj (q, obj);
   query_want_return_value_for_field (q, field);
   query_search_by (q, cust_id);
   QueryResult * result = query_run (q);
   char * surname = query_get_val (result, field);
   return  surname;
}

If the the config file did not specify a class whose name is 
"Customer", and that class didn't have a field caled "Surname",
then your compile-time function returns NULL.  SOL.   So if you 
really have to have compile-time interfaces, you can.

However, its not clear to me that compile-time interfaces are 
of any use, since most of the 'interesting' data will be dynamic,
run-time, and the gui's will have to deal with that.

> I think that we can certainly come up with some hard-coded
> requirements for data objects, and some flexibility for extentions.
> For example, with a contact-database we can come up with the
> required information:
> 	GUID, Name
> Some Optional information (necessary for some instances):
> 	Terms, Credit
> And a lot of variable, flexible information:
> 	Contact Info
> 
> Basically, no matter how flexible you make the system, you absolutely
> need this basic information to be present.  I can't see how you could
> have it any other way.

This is an idea worth exploring.  However, I suspect that once 
you have the mechanism in place to deal with some "config-time" 
data, it'll be easiest to assume that all of the data is specified
at config-time.  (With the exception of books, GUID's, and things 
like create/modify/destroy events)

> > > Again, this is describing the state machine process, not the data
> > > structures themselves.  Sure, the process can be scriptable.  As I
> > > said, that part should be done in scheme.  
> > 
> > Scheme is too general.  You don't need scheme to describe a state
> > machine.  I don't want to force sysadmins to be coders, much less
> > scheme coders.  I want something that a smart accountant could set 
> > up.
> 
> So you propose creating yet another extension language?  

No, at least I wouldn't call it that.  It would be a 'declarative'
language: something that can declare the field names and types of
objects, and pretty much nothing more.  

Think DTD, think XML.  Think of something that mght look like the 
glade file format, but different.

To be practical, it might happen to look like scheme forms and not XML,
but what I dearly want to prevent is to have the 'declarative' file have 
arbitrary algorithmic/functional/tail-recursive/lambda-laced scheme
code.  

[... snip stuff about billing customer hours ...]

> > I just finished coding the exact same object just a few months ago, and
> > I put it in 'gtt'.  I think I got it right there.   
>
> I'm trying to find it in gtt to see what you did.  As I said earlier,

if you have the source, look at "design.txt" and  "proj_p.h".
Otherwise, the strucure is mirrored in the GUI.  Note that different
billing rates apply to different sub-projects, not different customers.
Tasks are individually billable at one of several different rates,
or might not be billable at all.

> > > I just don't want
> > > to do that work ;)
> > 
> > It might actually be less work than what you are embarking on.  
> > Potentially a *lot* less.  Really.
> 
> Considering the contact database is done (except for storage and
> complex searches), I don't think so.  

OK, Well, its true that one can hard-code stuff fairly quickly, in part
because there are few conceptual problems.  But I've become
disenchanted with that approach.  Its boring, its inflexible, its hard
to maintain, hard to extend, hard to make interoperable with other
systems (bonobo be damned), etc.  I know that there is a better way.

If the correct tools/infrastructure existed, it could be a *lot* easier 
to create new, complex apps.  However, creating the right tools & 
infrastructure is a lot of work...

> >  Conceptually,
> > the query must be representable as a tree, with AND/OR to join the
> > branches, and objects (aka tables) & field names & comparison ops 
> > appearing in the leafs.   Anything more complex than this is too much.
> > 
> > All we really need to do is to extend it so that arbitrary objects
> > and fields can appear in the query.  This means moving away from
> > the enums in sort_type_t, pd_type_t and pr_type_t.  Maybe these 
> > should be replaced with strings.  I think if you made them strings,
> > then it would be sufficient to get the function that you want.
> > I don't think you need anything fancier than this.
> 
> Quite honestly yes, this is sufficient.  

Do you think you have enough info to proceed with this kind of an
extension to query?  Or do we need to look at it a bit more carefully?

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933