Business Processes

[Derek Atkins]

There is one problem with this data-driven model: Many data objects
contain internal data structures and points to other data objects
which must be maintained in the data structure but should not or can
not be displayed/edited to/by the user.

For example, a Customer has a list of Jobs.  This list is maintained
in memory similarly to Account maintaining a list of Splits.  The
Customer GUID is stored in the Job, and the Job 'adds itself' to the
Customer.  But note that this list of Jobs (or list of Splits) should
not be stored.

What I'm reaching here is that we need more information to explain
what fields in the data structure are ephemeral, as well as which
should be visible (and when), and which should be editable (and when).

It is not, by far, a simple problem.

-derek

linas@linas.org (Linas Vepstas) writes:

> On Sun, Nov 25, 2001 at 06:56:07PM -0500, Derek Atkins was heard to remark:
> > Mostly..  I'm very new to this GUI thing, and dynamic GUI is even
> > further out of my normal purview.
> 
> Its easier, actually.  First, write a traditional hello-world 
> with two buttons.  Be sure to hook up the buttons to C routines 
> that do something. Use gtk_signal_connect() to do this.
> 
> Next, design two buttons with glade.  Now, all you have to is 
> call glade_xml_new("/some/path/to/glade/file")  and then you
> call glade_xml_get_widget ("name that you gave to some widget");
> Then you use gtk_signal_connect() same as before.
> 
> The point being that you can give any widget any name you want,
> and then ge a pointer to it simply by asking for it by name.
> 
> > > At the bottom of each GUI window is a set of buttons and/or pulldown menus
> > > that allow you to move to the next state.  Some of these buttons are
> > > greyed out or invisible, depending on who you logged in as.
> > 
> > How do you dynamically add/remove buttons from the bottom of a dialog?
> > Yea, I know -- probably GUI programming 101.  
> 
> Yes it is ... I'm going to pass on this one. 
> 
> > > If you follow my earlier example, than you don't even need to have the
> > > GUI dialogs be hand-coded. They could be glade dialogs coupled to 
> > > confile-file-run-time object definitions.  Make everything run-time.
> > 
> > This works only so far as you can configure all your widgets in guile.
> 
> You mean 'glade', not 'guile', right ?
> 
> > You somehow still need to signify your 'extra' widgets that guile
> > doesn't know about.  
> 
> There are ways of dealing with this.  It doesn't hurt to ignore this 
> issue for now.
> 
> > To me it's still not quite straighforward how
> > someone would write the code to implement a generic dialog like this.
> 
> I'm not sure of which part of 'like this' you refer to.  
> However, keep this in mind:
> 
> A GUI dialog is just a tree heirarchy of widgets.  Leaf nodes can be
> almost any widget.  Interior nodes must be 'containers' that can hold
> other widgets.  Each node is a widget of some type (e.g. 'button', 
> 'text box').
> 
> In glade, you can assign any name you want to any given node.  
> You can then ask for that widget by name.  You can then tell the
> widget to display itself.
> 
> > You still need the C code to attach widgets to data structures.  Glade
> > wont attach a GNCAmount or CurrencySelect widget for you; you have to
> > do that yourself (in C, presumably).  
> 
> Yes, exactly. But when you read the config file, you read four strings:
> one string was "currency".  So your c code creates a "currency"
> object.  The second string was "MyWhacked_CurrencyEditor".  You
> ask glade create an instance of "MyWhacked_CurrencyEditor", and to
> give you a handle to it.  This is a handle to your dialog window.
> It will not display on the screen until you tell it to display;
> it lies dormant.
> 
> The third string in your config file is "MyWhacked_TextEntryWidget";
> its a part of the dialog, its a box for inputting text. You ask glade
> for a handle to this too.  The fourth string is "entry", which tells
> you that the the handle you have is in fact a handle to a GtkEntry
> widget.  That means that your C code can now call 
> 
> gtk_entry_set_text ((GtkEntry *) handle, gnc_currency_get_value (currency));
> 
> and of course:
> 
> gnc_currency_set_value (gtk_entry_get_text ((GtkEntry *) handle));
> 
> i.e.  the first string was converted to a C struct by a big case
> statement that knows about every possible  object in gnucash.
> The fourth string was converted to a C struct by a big case statement
> that knows about many gtk input and display widgets.
> 
> Well, its not a case statement, its a 
> 
> if (!safe_strcmp(val, "currency"))  { 
>     GNCCurrency *currency = gnc_currency_new();
>     ...  
> }
> else if (!safe_strcmp(val, ...)) { ...}
> 
> > > Like I said, 'been there, done that'.  I know of a better way, and
> > > that's what interests me.
> > 
> > If it's been done, then why doesn't it actually exist in the code?
> 
> Rather, "I've been there, done that, the old-fashioned way, and now,
> I am ready for the new way".  Its not in gnucash yet, becasue I haven't
> started scratching that itch.   
> 
> 
> > > "If you look in the src/backend/extnsions directory, you'll see that
> > > I've already got SQL tables defined for Customer, Vendor, Employee, and
> > > Job.  Sure, what I've got isn't all that extensible.  I admit it.
> > > But the code is almost there, its not hard to write, its
> > > straight-ahead".   
> > > 
> > > And, for me, tedious and boring.  You can create the sql backend for
> > > your new stuff, it might take you a few weeks, maybe less, maybe more.
> > > Theres nothing technically challenging about it.  Its just tedious.
> > 
> > Sure, it's tedious and boring, but at some level it still needs to be
> > done, no?
> 
> No.  I want to write a tool that will do the SQL automatically for me.
> I won't have to deal with hand-coded sql ever again.
> 
> 
> > > I know how to go to the next level.  With the right tools, one could 
> > > create everything you are creating, in about *one day*.  Not weeks 
> > > or months but ONE DAY.  The GUI, the backend, the reports, the graphs 
> > > (we haven't even talked about report generation or graphs!) 
> > 
> > What "right tools"?  Do these tools exist?  
> 
> Yes, there are many commercial tools that do this.
> 
> > If so, why aren't
> > we already using them?  
> 
> They're commerical.  And the open-source analogs are half-baked.
> 
> > If not, well, that's why I didn't use
> > them ;)
> 
> I didn't say you should use them.  I said "lets create a mini-tool
> of this kind for our own use."   The module system is a part of it.
> The extensibility framework you're creating is a part of it.  The 
> configurable ledger is another part of it.   The state machine 
> would be a fourth part.  And the specify-objects-in-config-files 
> would be a fifth part.
> 
> We are already going down the path of creating our own home-grown
> configurability framework.   I don't think we should stop.
> 
> We have to do this home-grown, because no other framework is 
> gpl'ed and ready-to-use and is powerful enough (and isn't insanely
> compliated).
> 
> By doing this, we will learn, the hard way, the ins & outs of 
> building configurable frameworks.  And by then, we'll be able 
> to start  arguing the meta-meta issues.
> 
> --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

-- 
       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