[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Data Dictionary
From: |
Derek Neighbors |
Subject: |
Re: Data Dictionary |
Date: |
19 Aug 2002 23:27:18 -0700 |
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
>
- Data Dictionary, Jeff Childers, 2002/08/18
- Re: Data Dictionary,
Derek Neighbors <=