>Hopefully Kevin will add some comments here as well, but here are the main differences that I know of: > >1. Visual FoxExpress includes a complete user interface that you can use in place of or in addition to the project manager for building applications. > >2. Visual FoxExpress extends the data dictionary with DBCX and includes a rich set of objects that interact with DBCX properties. > >3. Visual FoxExpress doesn't require you to hand code data environments in adataenv.prg. > >4. Visual FoxExpress uses the standard VFP menu editor and GENMENUX to create menus based on classes whereas The Mere Mortals Framework uses menus actually created in .VCX files. > >5. Visual FoxExpress business objects take a little less memory than Mere Mortals do, but in some cases the Mere Mortals business objects are more flexible when creating parent/child forms. > > >I don't know of anyone that's done this yet, but because both products are based on Codebook they could be used to complement each other, IOW, you could use VFE to build the app and VFE's classes where appropriate but you could also plug in some of the MM classes in places where you think they're more suited to something you're trying to accomplish. > >These are off the top of my head. I'm sure there are others as well. I am looking for framework which will be a part of object-oriented software development process. All of us are reading a lot of deferent "Design Patterns" and "OOP software development" books. It seems to me that codebook type frameworks with bigness objects fits very well to what I need. I would like to present a replay from Ed Leafe to some my questions (with his permission). I have heart that AccountMate was build with codebook methodology. Can somebody from this company answer?

On 12/15/97 2:00 PM, alexander.golovan supposedly said:

>We are evaluating frameworks for my company. I went through Codebook and
>built simple application. Now I found that Codebook for Mere Mortals, Fox
>Express and some other companies are working on different approaches for
>"pure" codebook methodology.
>What are your recommendations? We do not need application generator, I was
>thinking about using Codebook for Mere Mortals, but recent review in
>FoxTalk for FoxExpress was very good. What is really important if we go to
>Codebook direction is to obtain most recent fixes just from one source.

   FoxExpress (FEX) and Codebook for Mere Mortals (CMM) are two quite
different products. FEX takes the original Codebook framework and greatly
expands it with extensive builders and wizards, and automates much of the
tedious work in class development in the framework. CMM is one company's
modifications to the Codebook framework, but doesn't greatly expand the
capabilities the way that FEX does. Both of them contain fixes to the
original Codebook classes, but not necessarily the same enhancements.

   With FEX, you are buying a rapid-application development environment
which uses Codebook as its basis. With CMM, you are buying an updated
copy of Codebook, along with support. The two really aren't all that
comparable.

   I also have my version of the framework which incorporates the latest
fixes and integrates the major enhancements to it, such as the eBizObj
class libraries I developed and some enhancements from Flash, but I do
not distribute it, since I wouldn't charge for it and am really not in
the framework support business. I make it available to all my clients at
the start of developement. There is another company, SAVI, which gives
away their enhanced and documented Codebook framework to anyone who can
give proof of ownership of the original Codebook. You can contact CT
Blankenship of SAVI at ctb@savvysolutions.com.

>We are concerning about "component" development, how Codebook strategy
>fits to this. So far I did not see something really new in Codebook
>bigness objects, it is just you build class container and put on the form.
>I have read review in the FoxPro Advisor, but it still did not answer all
>my questions.

   I suggest you take a better look at the business objects - they are
true n-tier components, and lend themselves to the whole COM/DCOM
approach to component development. They handle all the business rules
without requiring a GUI layer; although you can add fields to the
container, that is not a requirement. They also separate the data
handling out into the cBehavior classes, allowing for changing the
backend data store without having to modify the bizobjs.

   Check out the internal messaging when doing a Save(), for example. The
toolbar (GUI) sends a message to the form (GUI) which passes it to its
bizobj (business), which then passes it to its Behavior (data). At any
point each layer can prohibit or modify the process, and can return a
value back to the GUI indicating the status of the Save() request.

   I am currently working on a pure 3-tier application with a division of
Mercedes-Benz in which the middle tier (the bizobjs) have no GUI
component at all. It works amazingly well!

   If you wish to have others' feedback on Codebook matters, you can post
your questions on my Codebook Web Support Forum - the URL is
.



      ___/
     /
    __/
   /
  ____/
  Ed Leafe
  http://www.leafe.com/

Alex Golovan,
Consultant - Development,
GTE Enterprise Solutions