Business Processes

Derek Atkins warlord@MIT.EDU
25 Nov 2001 17:17:33 -0500


linas@linas.org (Linas Vepstas) writes:

> OK,
> The following is a very very half-baked writeup, starting at square 1,
> dashed off between interruptions.  Its very simplistic, possibly too
> simplistic; but maybe it'll give us a vocabulary to start with,
> so we can move on to the hard conversations.

Ok.

> I'm going to put the object definitions in ascii files.  The actual
> format will be scheme forms or xml or something, but for right now, 
> I will just use space-delimited.

Ok, although at this point I've got the basic objects defined.
Perhaps not flexibly, but defined nonetheless.

> # this is a comment card.
> # the following is a pretend address
> 
> BEGIN OBJECT "Address"
> FIELD "Surname"  STR  
> FIELD "City"     STR
> FIELD "Zip"      STR
> END OBJECT
> 
> BEGIN OBJECT "Order"
> FIELD "Shipto"  "Address"
> FIELD "Amount"  NUMERIC
> END OBJECT
> 
> First note that this is purely declarative; nothing functional, 
> nothing algorithmic, no lambdas.  It just declares types.
> (Maybe Tyson Dowd could tell us how to best build a declarative 
> file format...)

I see where you're headed, and it makes some amount of sense.
I'll even refrain from commenting on the incomplete objects --
you're trying to talk about the abstract by giving examples.
I wont discuss how the examples are broken ;)

> This looks sort-of looks like SQL structs, except that I can use a type
> after declaring it. 

Ok, sure.

> So much for the easy part.  The hard part:
> 1) how to turn this into something that will hold data?
> 2) what are the programming API's?
> 3) how to attach this to the GUI?

None of these are, IMHO, the hard part.  The hard part is the your
un-written #4 which is the state machine that walks users through the
various screens to enter the various (necessary) information into the
system.

> Lets start with the api's.   The basic api is a set of object and 
> field iterators:
> 
> char * get_next_object();  // first time its called, returns "Address"
>                            // the second time it returns "Order"
> char * get_next_field (char * obj_name);
> // so that 
> // get_next_field("Adress") returns "surname"
> // get_next_field("Adress") returns "city"
> 
> char * get_field_type ("City"); returns "STR"

Although very extensible this seems extremely cumbersome.  For the
common, required elements one would think there is a better way, or at
least a shortcut.

> -----------------------------------------------------
> Lets move on to GUI's.  There are multiple choices.  

[snip]

> A better GUI would be to tell the config-admin (the person creating
> the config-file) to use Glade.   Each glade can have a name.  Those
> glade widgets whose names correspond to a field name in the object
> will get that fields value poked into it.  
> 
> The glade approach will result in a nicer gui, and also potentially
> allow several objects to be displayed in one window.  Thus the glade
> dialog might display:  
> 
> /Order/Shipto/Surname
> /Order/Shipto/City
> /Order/Shipto/Zip
> /Order/Amount
>
> The upside is a nice gui, the downside is that creating a new gui
> requires the use of glade.  

Honestly, I don't think using glade is all that difficult.  I was able
to use it in a matter of hours to create (for the first time) a
half-dozen dialogs.  But I do see your point.

> Note: if we wanted to be really cute and clever, we could get the config
> info out of the glade file.  For instance, if the glade file had a
> widget named
> 
> /Order/Shipto/Country&type=STR
> 
> we could deduce that the "Address" object should contain a field called
> "Country" of type "str".   (It might even be possible to wrte a glade
> extension to provide more support for this, directly).
> 
> Clearly, there are a number of issues at the next level of detail, 
> but assuming these are solvable, waht other major issues are there?
> Do you beleive a scheme like this would this work for the GUI component?  
> Should we proceed to the next level of detail? 

Honestly I'm not 100% convinced something like this would work.  I
mean, sure, there is probably some way we could post-process a glade
description file into a C file and compile it.  But Ewww.

Also, this doesn't help when trying to use GNC widgets that Glade
doesn't know about.  How do I use glade to insert, say, a
commodity-select widget or a GNCAmount widget?

If you look under the Extensions menu you'll see that I've already got
widgets for Customer, Vendor, Employee, and Job.  Sure, what I've got
isn't all that extensible.  I admit it.  But the code is there, it's
done, and it works.

There is still a list of things that I still need:

 1) New/Edit Order
 2) New/Edit Invoice

These create the objects; they don't provide the functionality to
fill them in, necessarily -- see below.

 3) Add Order Entries (this looks like a SplitLedger).  One question:
    should you be able to set the owner of the Order from this window?
    What other information is set in #1 above that you cannot set here?
 4) Create an Invoice from a set of Orders -- select existing Order Entries
    to include in the Invoice.  The same question can be posed here as in #3.
 5) Post an Invoice (to A/R or A/P)
 6) Process Receipts/Payments (for A/R or A/P)

Obviously you should be able to work backwards in the process as well
as forwards.  Also, you should be able to skip stages as well if they
don't make sense to you.  This is the flexibility that I don't know
how to build.

> Let me defer the storage/sql questions till later.

Ok, but one thing to keep in mind: What is the point of modularization
if there exists one module that must know about all the others?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available