Custom Field Property in BO Mapper


Author
Message
Ben Hayat
Ben Hayat
Advanced StrataFrame User (946 reputation)Advanced StrataFrame User (946 reputation)Advanced StrataFrame User (946 reputation)Advanced StrataFrame User (946 reputation)Advanced StrataFrame User (946 reputation)Advanced StrataFrame User (946 reputation)Advanced StrataFrame User (946 reputation)Advanced StrataFrame User (946 reputation)Advanced StrataFrame User (946 reputation)
Group: Forum Members
Posts: 374, Visits: 1.2K
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
Reply
Pertti Karjalainen
Pertti Karjalainen
StrataFrame User (146 reputation)StrataFrame User (146 reputation)StrataFrame User (146 reputation)StrataFrame User (146 reputation)StrataFrame User (146 reputation)StrataFrame User (146 reputation)StrataFrame User (146 reputation)StrataFrame User (146 reputation)StrataFrame User (146 reputation)
Group: Forum Members
Posts: 54, Visits: 4K
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

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Threaded View
Threaded View
Ben Hayat - 19 Years Ago
Henry J Fay - 19 Years Ago
Ben Hayat - 19 Years Ago
Pertti Karjalainen - 19 Years Ago
Trent L. Taylor - 19 Years Ago
Pertti Karjalainen - 19 Years Ago
Chan - 19 Years Ago
Henry J Fay - 19 Years Ago
Charles R Hankey - 19 Years Ago
Richard Keller - 18 Years Ago
Trent L. Taylor - 18 Years Ago
Richard Keller - 18 Years Ago
StrataFrame Team - 18 Years Ago

Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search