Re: Data Dictionary

[Derek Neighbors]

You are describing relevant stuff to AppServer, however, currently I
havent been doing a lot of work in that area.  I think we need to get
AppServer farther along before we can get too into these discussions.

-Derek
On Sun, 2002-08-18 at 06:28, Jeff Childers wrote:
> Derek,
> 
> Has any kind of data dictionary or data structures definition been started
> yet? If not, I have a concept that I've been using over the last couple
> years in our development that seems to really shorten development time.
> Basically, it works like this (lots of detail left out of course):
> 
> Define Possible Properties (think fields in this case) of Objects (think
> tables) as one of a few pre-defined types:
> 
> 1- Primary key (one per object, user-invisible)
> 
> 2- Surrogate key (user-visible object key e.g. customer, item, vendor "ID"
> number. All characters allowed, read/write)
> 
> 3- Local value ("data"; e.g. units ordered, contact phone no, company name,
> etc)
>       - list/option values can be set and edited right in data dictionary
> for combo/list fields 
>         this can be a list of values or a SQL statement that returns the
> list
>       - generic data types (char, int, date, logical, etc.)
>       - meta-types: e.g. phone number, zip code, currency, etc.
> 
> 4. Composite value (i.e. "calculated field". The dictionary stores the SQL
> used to calculate this field at runtime for any time it is used or
> displayed. Logic in the object class handles calculating the value on the
> fly whenever the property for this field is accessed from the object.
> Nothing is actually stored in the table - this is a logical field with no
> physical counterpart). Examples: line item subtotal, order total, order tax,
> order freight, A/R account distribution total for invoice, inventory on-hand
> quantity, etc. So ALL subtotal or aggregated fields are calculated on the
> fly. It becomes very easy to edit / maintain the calculations at the data
> dictionary level, and avoids many data integrity errors.
> 
> 
> Now you add default logic to your base classes for data entry controls that
> determine behavior when the control is created on a form depending on the
> data type. The only property you are required to set locally is the field ID
> - the control looks up the typing and other information from the data
> dictionary.
> 
> TYPE                  BUILT-IN BEHAVIOR
> ================
> ====================================================================
> Primary keys  Never shown, only possible behavior is set self to read
> only)
> 
> Surrogate keys        Implement lookup logic when in edit mode via right click
> menu or 
>                       create a small lookup button next to field on init
> etc). E.g. 
>                       Order No control on Invoice form lets you "lookup"
> the 
>                       original order form. Customer no control lets you
> "lookup" the
>                       customer card and/or select a different customer. 
>                       Implement optional search logic to trigger lookup
> form/utility.
> 
> Local value   Set all properties for control from base data type
> definition:
>                       E.g. "list" fields get a combo box, "phone no"
> fields have their 
>                       input mask set to system default, general
> validations are set, etc.
> 
> Composite value       Read only at runtime. However, right click or 
> runtime-level
> control
>                       allows "drill down" to the records that are used to
> calculate the 
>                       value. E.g. right-click on AR Debit balance field
> and see all the 
>                       individual postings that make up the figure. You can
> do a lot more
>                       with this.
> 
> You could define a couple more types (e.g. true "drill-down" and "drill-up"
> types) but you get the idea. Here's where the advantages start:
> 
> 1) The data dictionary becomes the central place where much application
> behavior and logic can set set or modified (think end-user customizations
> like the ability to change list values easily). 
> 
> 2) Data dictionary can now be used to enforce core validations at all levels
> of the application. E.g. you can open the entire table for browsing in a
> grid -- each individual cell control relies on the dictionary settings to
> validate, calculate, format, etc. 
> 
> 3) Adding controls to forms requires only to set the field ID to enable the
> majority of functionality that you typically want. There could be a single
> control that even includes the object's caption (from the data dictionary).
> Designers could just use that single control when building forms and not
> have to worry about 10 different widgets - the control will self-select the
> appropriate widget.
> 
> 4) Upgrading the base control class can upgrade application-wide behavior.
> 
> 5) Key modules such as lookup forms, drill-down and drill-up become
> automated and can be maintained in a single place.
> 
> Detail record entry (e.g. sales order lines) can be easily handled in a grid
> where each cell is a baseclass control. If the wxPython grid widget isn't
> working sufficiently well to handle this we can create our own grid control
> without enormous effort I think.
> 
> What do you think? If you like it, I could flesh it out into something more
> tangible for peer review and comment.
> 
> 
> Regards,
> 
> Jeff Childers
> 
> 
> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf Of Derek
> Neighbors
> Sent: Friday, August 16, 2002 4:25 PM
> To: J. Childers
> Cc: address@hidden
> Subject: Re: Supply Chain Spec Volunteer
> 
> 
> Yes we woudl love it, the source of that pdf is in cvs and is actually
> in docbook (xml).  You can submit patches to it via address@hidden or
> address@hidden
> 
> Neil Tiffin was heading up specs, but has other committments now, so
> sending to the core will work until we find a new 'head' of application
> speficication.  It's really a great job, in fact it even pays well, a
> 200% increase per day is *GUARANTEED*.  (assuming one is foolish enough
> to believe 0*200 = something valuable)
> 
> -Derek
> On Thu, 2002-08-15 at 14:22, J. Childers wrote:
> > Hey, do you guys want somebody to start fleshing out the SupplyChain.pdf
> document? I assume that
> > it's a spec of sorts...
> > 
> > I would love to work on that. I have lots of detailed ERP product
> experience (from coding to
> > implementation) and tons of opinions :).  Who's in charge of specs anyway?
> > 
> > Regards,
> > 
> > Jeff Childers
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > HotJobs - Search Thousands of New Jobs
> > http://www.hotjobs.com
> > 
> > 
> > _______________________________________________
> > Gnue mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/gnue
> > 
> 
> 
> 
> 
> _______________________________________________
> Gnue mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue
>