In a post that got trashed (along with with the one I had replied to, from Pertti, and replies from Trent and Chan, when the forum indexing went south), I suggested that xCase (efficient ERD design, extensible attributes) would be an ideal feed into the DDT, assuming there were an API available in development and at runtime.  We've been doing something like this for years in the VFP framework we use (Visual ProMatrix), and the productivity gains, both in design and maintenance, are incredible.

Yes, we sing from the same hymn book here

Just imagine this scenario:

1. You have a bunch of Startaframe apps consuming data from one central data warehouse.  A huge number of your screens reference a customer support phone number from the customer support table. 

2. Phone company runs out of phone numbers and decides to add one more digit to the end of the phone number.

3. Now you, the programmer, need to go through ALL of your screens that reference not only the customer support phone number, but all other phone numbers as well, and change the input masks every(friggin')where! 

4. You groan and you moan and off to work you go, praying to find all phone number instances AND to not get so disgusted by this robotic task that you start making typos, which brings up the issue of all of this regression testing you have to do on all of your apps in order to cover all of the phone number instances in all of your forms.

5. UNLESS you have seen the light and been saved by A.D.D. (Active Data Dictionary, not Attendtion Deficit Disorder, you fool -- pay attention!) 

Imagine using this Object Oriented "data metadata" concept instead:

- Your A.D.D. has one domain table with custom data type "domains".  A phone number would be one of them, with an input mask of, say, (###) ###-####, along with any number of other default properties you might want to set for a phone number (e.g., default caption.

- This domain table in turn would be referenced by the data dictionary table, which includes the input mask and any number of properties for each data column in each table in each database you have in your data warehouse.

- However, to speed things up tremendously AND make your data display and behave in a uniform way across your apps AND to avoid typos, do the next step!

- When you edit or add entries into the data dictionary, rather than hard coding for example the phone number input mask for each phone number, you would just enter a reference to the domain table's phone number.

- Now you must see where I'm going with this, no?  When to phone company adds that blasted digit, all YOU need to do is go to your domain table and change the input mask there, in one place, just once, and you are off to Hawaii!  Your boss of course thinks that you are locked up in the dungeon, laboring 24/7 over the average of 5 phone number changes in the 15,000+ forms AND when you are done with the changes, THEN conducting thorough coverage and unit and regression tests to make sure nothing, and I mean NOTHING broke in any of those 5*15,000 fields.

This is, really, just a familiar concept in a new territory.  Sounds like class inheritance applied to data, doesn't it?  Modify in one place, change everywhere -type of thing.  And the subclasses (entries in the data dictionary) act in an OO way, too, since you can overwrite the default behavior/visual properties coming from the parent class (domain table), as needed.

In order for the concept to work, however, the data dictionary has to be active, so that your apps can dynamically refer back to it as they generate screens, web services, and what have you.  I'm no .NET Wizard, nor do I want to be (that's why I bought Strataframe, for Pete's sake), so I don't know how to plumb something like this into the framework, but if .NET is a serious platform, which I believe it is, there MUST be a way to do this, without or with a lot of handwawing and smoke and mirros.

Can I make it any clearer?  I demand an active data dictionary!  Now!!!  ...Pretty please. 

Pertti

I appreciate your time that you put into that post, and I see the validity of what you are saying.  However, using your example from above you could easily subclass a MaskedTextbox and create a class specifically for phone numbers and everywhere you have a phone number, use this control.  It would literally be less than 10 lines of code...once, and would ultimately be MUCH faster than being data driven which would require a query to either a database or an embedded XML (which would be much faster than being in an external database).  I am not saying that we will never have this, but I can confidently tell you that it will not happen any time soon. 

In response to Hank's post, I think he is referring to something entirely different.  I think that the API in regards to the DDT is a great idea and is something that we have contemplated doing.  I do not know, however, if or when this will be implemented.

thank you for your response.  I am very sorry to hear that you guys won't be joining my choir any time soon...  I guess I will have to build this thing all by my lonely self. 

Unless........

I think I'm talking about the same thing as Hank.  I know something about his mindset, having worked with him and his products in the VFP end of things for many years.  But Hank may (freely) correct me if I'm wrong.  I have seen this approach do wonders speeding up development and maintenance efforts, over and over again.  It also works with amazing speeds on a few VFP frameworks I've worked on (Promatrix and F1 Tech come to mind), even with HUGE datadictionaries attached.  If you have a fast enough data engine dishing out the metadata, it is no big whoop, trust me.  For example, when a form pulls up, the data engine needs to be queried only for the fields showing up on the form, and with proper indexing it is almost instantaneous.

I understand that I can do this stuff in code, but over there it is static, vs. over on the "promised metadata land" it is dynamic.  What's the diff?  Well, for starters, it is still much, much easier to maintain your metadata if it is in tables -- you can even hot-swap changes on-line, to a running application, if you'd like.  So, in my example, if the phone number format changes, all I need to do is run a metadata change, no need to update programs etc. on the customer side.  This is a small thing, granted, but I use it only to illustrate the difference.

Additionally, I used input mask as but one tiny example.  Active data dictionaries can manage a huge number of properties and even some dynamic methods and display/data handling classes, if you want.  Putting all that in static code (separately for each application you build, I might add) is an inefficient way to do things in this front.  This, of course, is just my (ever so) humble opinion.

Anyhow, I don't want to take any more of this forum's bandwidth with this idea, since it doesn't sound like this is an idea whose time has come around here (if it ever will).  I still like Strataframe a lot, no question about that, but I also still mutter under my breath when I'm entering same property values into various forms over and over and over again.

Thanks for listening! 

Over & out.

Pertti

I agree with you for phone# mask. What about maxlength for character field? I think we need to set maxlength for each character field to prevent "truncate" error while update data back to database. I don't think I would subclass each of them. It would cause me to have hundred of textbox subclass.

I have been Promatrix user since two years ago. I really feel amazing when I see the framework allow me to set input mask, caption, max length in a metadata. It always save my life, as standization is always FIRST priority in my dev team.

Thank you

Of course there is one huge advantage in working in VFP when using live metadata: we embed the key tables in the EXE, and use SEEK against them (typically once per control, putting the field record object on the control for later use).  It is very fast. I haven't seen a need to have changeable metadata on a user site, but I know others have, and in those instances the EXE can be built without them (losing about 15% in speed of the DD seeks, but still acceptable). 

Most importantly to me, building the app using metadata is the key to managing complexity.  From our perspective, Business Rules, both data and UI, belong in metadata, not buried in an application.  When I want to change attributes for a field throughout the app, I change the Domain (which I created in xCase) attributes used by that field, regenerate the Database and the Data Dictionary, and it changes everywhere in the application (the controls being subclassed to respond to metadata regarding width; and the builders we created being capable of sorting through a design surface and resizing controls to what is in the metadata, to handle placement issues). 

In the online classes (now all videos) for using our stuff, I start off the first session with challenging developers to "use your head, not your fingers" in developing software.  Metadata, and associated tools, remove about 80% of coding from an application, leaving for the most part the interesting stuff that's fun to do.  Not including documentation, although David Le Mesurier has created a tool that uses the metadata-stored help information, takes a screen shot of a design surface, and puts the the two together into a West Wind Help Builder topic, broken out by the controls on the design surface with the metadata-stored help information.  It can actually hit all the design surfaces on a form automatically.

Now, it may be that in .Net it makes more sense to stuff things into assemblies built around each BO.  Especially since Orcas apparently won't have real local data storage, based on what I've read from Rick Strahl.  With a little development-mode management of what entities have changed, that may be the quickest way to help Pertti (and myself) out of the burden of typing for living. <s>  Heck, DTE programming can't be that hard, right? (I think it fits somewhere between Dante's 3rd and 4th levels, where one is condemned to writing CTYPE casts all day...)

Anyway, I think that extending the DDT into an extensible, fully integrated tool at development and runtime would give SF that product distinction which (marketing people say) every successful product has.

Richard

I guess I am little confused as to what youa re trying to accomplish.  You you elaborate a bit more?  Are you referring to the DDT or something else?

Richard

You might be better off defining one table that containg data dictionary values...

ddv_pk
ddv_FieldName
ddv_FieldValue
ddv_pk_Parent

The FieldValue would be a variant data type to store whatever you place in it.  Then you could pull all of the values for a parent record in one query and add some sort of maintenance program to allow the end user to define the custom fields.