Tom,

I will answer in line below.

>Steve;
>
>Coming from the engineering world I like brief descriptive answers and no “fluff”. Having a sense of humor helps get you through life. When it comes to frameworks and languages I have used more than a few. Each one has benefits and drawbacks. Even if you created your own language/compiler and framework it would have limitations.

Couldn’t agree more <s>


>It is really great to discuss the nuts and bolts of a framework. Looking at a chart on the wiki may be of assistance to some degree to evaluating frameworks but you really have to “get your hands on it” to know how YOU like it. Some one else may not like it for a variety of reasons. Needs differ as well as approaches to software development.

Absolutely. I like VPM for a lot of reason, but I am fully aware that it won’t suit everyone, and probably shouldn’t. Otherwise we’d all be cookie cutter copies of one another, and that wouldn’t be much fun. <g>

>I would love to hear from people who use frameworks discuss in some detail (as has been done throughout this thread) how specific things are accomplished. Such as but not limited to:

>1. How is data handled

Whew, big topic <s>. I’ll cover a few things, and wait for more specific questions.

The DD has a rich set of attributes (a much larger set than is available in the DBC) which can be used throughout an application. Code can be placed in the DD which will be fired by the Valid and When events. This code is written to a procedure file which is executed in the application when called by one of the VFP events.

VPM has its own interface (the Data Builder or DB) for handling data creation/editing. This is due to the fact that VPM is driven by its own Active Data Dictionary (DD) If you are using the native interface to create/edit data a table/view is added or updated in the DD when the VFP designer (called from within DB) is exited. A DBC can be created/edited from within the DB

I use xCase and xCase2VPM which recreates the DD form scratch each time the model is imported form xCase, so DD maintenance is not an issue if this toll is used.

>A. Views
Within an application, VPM will choose between a local view or a remote view depending on a logical attribute in the DD. IOW, Local or remote data can be selected granularly for each view. VPM defines 3 parameter types which are used throughout the classes. (1) PKVALUE: PK parameter – used by a child to find its parent, to check for a unique value on a backend, locate the description field to be displayed when the field holds a surrogate key FK. (2) ParentPKValue: used by a Parent to find its children. (3) Find: Used with a SQL find form to select records. User can define parameters as needed, but these 3 are pre-defined and used extensively by the framework. A 3 lines code snippet must be placed in the BeforeOpenTables method of a DE (manually due to the lack of a WRITE METHOD method for the DE in VFP, otherwise the Builder would handle it.


>B. Tables
As previously discussed, VPM, for a variety of legitimate reasons used its own DD, and Data Engine. This necessarily includes the PK. PKs are set in the DD, not in the DBC. In fact, setting the PK in the DBC will cause conflicts in some cases. Candidate keys can be used in the DBC, but require consideration for some issues. For example, a filter on deleted() is necessary for the candidate key, so two tags are needed, on with the filter on deleted() for the candidate tag, and a normal tag without the filter. Most other DBC functionality works fine in VPM, although some things DBC attributes are ignored or simply useless in VPM. For example, captions are handled in the DD, with optional separate attributes for field captions, and grid header captions. Syncing views attributes with their Table attributes takes a couple of mouse clicks

>C. Other back ends

VPM remote views can handle any SQL compliant back end as long as the developer considers language difference in his code. xCase2VPM will specifically generate SQL Server compliant views.

>2. Saving data
VPM handles Saves in its RI engine. The actual RI/Save code is in the application object, called from forms. Will prevent duplicate PKs, update/deletes are ANSI compliant, to assure data integrity.

>3. COM objects

Will have its own COM object later this year when the ProMatrix DataServer is released. Otherwise, writing COM object is no different than using Native VFP, with the usual considerations for COM rules, such as those on UI.

>4. Web enabling

When the ProMatrix DataServer and v7.5 is released later this year, the DD will be accessible from any front end capable of talking to a COM object form any network connection. Web connectivity is limited at this time.

>5. Speed of instantiation

VPM, like any good framework, contains a number of libraries. EXE size will usually exceed 5MB. Instantiation is reasonably quick on a decent VFP level platform. Actual times will vary all over the place depending on hardware (memory, HD, network, etc.) A multi MB EXE will certainly take longer then a 15K VFP loader <g>, but I haven’t seen anything unacceptable.

>The list could go on. At the same time we may have answered specific questions that will assist many in making a better decision as to which framework to use and why.

I’m sure it does <g> I have barely scratched the surface, and am not even sure I have addressed the questions as you meant them. More specific question would be helpful, better yet, get the Demo or a copy of the standard (limited) version, and try some of the basic stuff, and ask questions as they arise. Be sure to get the free demo of xCase and xCase2VPM (5 entity limit) to see the power of this combination.

>I have an open mind and am always willing to listen and learn. At the same time I teach those around me what I know. After playing this game for 20 years I think I have learned a few things but realize I know less than 1% of what I would like to know. At this point of my life I concentrate on what gives me the results I need. So far I have not taken the wrong path and if I did I have not realized it. :)
>
>Tom
>
>
>>>Steve;
>>>
>>>“Real Programmers” use granite stone tabloids and iron cutting tools. Fred Flintstone told me so. :)
>>>
>>>Tom
>>
>>
>>Tom,
>>
>>GREAT <g> When things get too serious, a good chuckle is invaluable.