It would be great to be able to create a "Custom Field Property" skeleton in the BO Mapper. This way, the dialog box can ask a series of questions and then create the formation of the property (with attributes) and the we can add any additional code there.

..ßen

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.

Trent,

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

Hi,

 

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

That's great about the possibility of a DDT API.

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.