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
or object name 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
__________________________________________________
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