>>So then is the correct thing to do to create an "I" layer set of classes that mimicks the Generic "A" layer and then redefine the Generic "A" layer to be subclassed from that?
>
>Hi Steve,
>
>in my opinion the MMF product was not really designed to be an optimal I-Layer type framework where customization is abstracted out over several layers. I-Layer type frameworks are great with application builders where the parts and pieces of the framework are assembled and reassmbled over and over again with little-to-no developer input. In this type of implementation your layers are typically a lot thinner and the code to handle functionality gets spread out a little bit better.
>
>Instead, MMF is more of classlib intensic type framework, where your common libraries are deeper pockets of functionality (which is already layered based on codebook evolution history) and the process of creating a new app is to make a sublassed copy of the core parts and pieces where your application specific functionality resides. This is much more similar to a smaller homespun framework... where starting a new app involves a flat out copy of your framework classes and tools.
>
>When working with MMF classes, your probably going to find the level of effort that has gone into making the common libraries is very comprehensive and detailed in such a way that in most cases it already handles everything you need it to, hard part is just finding what you need when you need it. Whereas with a true I-Layer type framework the canned functionality is little lighter and it's expected that the developer(s) groom in details over time specific to their needs and standards.
>
>So in light of this, I found when working with MMF it's better to go with what I like to call 'a tool box approach' for working in my own class library customization (as opposed to following suit with the I-Layer mentality). My thinking here is that a toolbox grows over time, so you dont really need to sit down with a brand new fresh copy of MMF and go thru a massive subclass exercise of creating your own layer of everything your gonna use frequently. My reason being is that your really dont know where you need to frequently enhance areas of the framework until you build several apps.
>
>Instead, follow suit with QuickStart functionality of setting app specific classes of the stuff you use most. And as you work thru fleshhing out those a-classes, keep asking yourself if the functionality your coding is either a)something you'll need to reuse over & over in more than one app; or b)is functionality your coding something you wished was already built into the framework. If the answer is a), then save the class definition to a lib in your own toolbox directory (for me, it's ..\common30\rox and this require a tweak to pathing in startmm.prg) instead of saving it the default a-classlibs created by quickstart. If the answer was b), well then post it up here for Kevin's review. One of the reason MMF is so comprehensive, and sometimes intrensicly complicated, is because there has been so much mass market developer feedback and enhancements built into the product over time.
>
>And as far as long-term development with this 'tool box approach', I've found that my first app or two I loaded up my toolbox libs with stuff I didnt really need in there (half the time it was handled already in the framework). Also, nowadays I typically only updte my toolbox libs post-project. Meaning when the job is done, I got back over all my app specific classes and cherry pick out copies of what I want added to my toolbox, then I leave the app as-is and rework the class into a generic implementation in my toolbox. Then when the client wants an upgrade on that app, I rework the originating app specific class to be a subclass of my toolbox lib and life is good. I find this approach extremely valuable because my toolbox classes end up being exercises in refactoring code, and code is always better the second time around ;) Plus too, often times when starting a new project, a string of light bulbs goes off and find myself saying "hey I already did this here, here, and here...." and I
>spend a day refactoring parts and pieces of other projects that I didnt initially anticipate reuseing again into my toolbox.
>
>HTH


That does help. Thanks very much for the information.


Steve