>Hi Bob, I thought I understood how to implement AbstractFactory for my own needs but now I'm a little confused. Following your suggestion above, wouldn't this mean that the only app level files that would need maintained with future framework updates is the classes.dbf stored in the app's data directory, and any changes you might want to make to the custom class your using as a substitute?

Right...

Because the built in instantiation of the AbstractFactory goApp.oFactory is set up to use classes.dbf... so, if you want to use your own error class instead of the one that comes will MM, you change it in classes.dbf. Every time there is an update you have to make the change again. Or, you could use a seperate copy of classes.dbf and make sure that any additions or changes to the frameworks classes.dbf were done in your app level copy.

Also, as you did, you can set up an instance of the AbstractFactory for your own uses, which would use a file other than classes.dbf.

Personally, I would like to see the default abstract factory support two files. It would look in aclasses.dbf first, and if it didn't find the key there, it would look in classes.dbf. This would solve two problems...

1. You wouldn't have to manually maintain ap level copies of classes.dbf, all you would do would be to duplicate a key that you wanted to override into aclasses.dbf.

2. You wouldn't need a 2nd instance of the AbstractFactory to use for your own uses... since be default goApp.oFactory would look in aclasses first, then in classes.

What do you think?

BOb