At 02:21 AM 7/5/00 +0000, Scott Parish wrote:
Does anybody out there have even the slightest clue about how to go about using AttributeProviders and SheetProviders? A select few terse hints on this subject would really help us (me) figure it out enough to start working on some howto's.
You might look at some of the recent posts which included an example of using GenericAttributeProviders to read from a MySQL database, and my reply explaining how to use a GenericTrigger to update that same database.
Am i wrong in thinking that DatabaseAPI is a completely separate solution to the same problem that ZPatters is suppose to address? Personally i have to give DatabaseAPI props for being quite easy to understand and use, while not sacrificing power.
Peter Coad's design approach (which ZPatterns is heavily based on/biased towards) emphasizes four major layers of classes in an application: 1) User Interface (GUI, forms, etc.) 2) Problem Domain (the actual application purpose) 3) Data Management (object persistence/lifecycle management) 4) System Interaction (interfaces w/hardware or other software) ZPatterns is focused on providing tools for transparent mappings between layers 2 and 3, while DatabaseAPI, as far as I can see (and I actually did play around with it today to get a feel for it), is focused on tools for building clean mappings between layers 3 and 4. In my mind, this makes them complementary tools, rather than competitors in any real sense. Indeed, looking at DatabaseAPI has shown me that there are some features I'd planned for ZPatterns (or already started) that I can scrap because DatabaseAPI has them and can easily interoperate. (Personally, I'd like to see a version of DatabaseAPI using PlugIns to structure its user interface, which I think could easily make it even cleaner and easier to use than it already is. It might then also be possible to reuse some of its plug-ins for functionality in areas of ZPatterns. But I digress.) So where do DatabaseAPI and ZPatterns overlap? DatabaseConnector has some functional overlap with Specialist. If you ignore the attribute, sheet, and trigger providing aspects of ZPatterns (and also look only at the raw functionality), the primary difference between a Specialist and a DatabaseConnector is that DatabaseConnectors will probably have methods to delete objects or change their data, which is a no-no for a Specialist because it's an encapsulation breach. Beyond this, there's a significant difference in intent between a Specialist and a DatabaseConnector (IMHO). A Specialist serves as a broker to access objects which fill a certain role in a framework, while a DatabaseConnector represents an object which manipulates "records" which are of "record types" and have "fields". Specialists use Racks to explicitly distinguish between problem-domain and data-domain concerns; you can probably do this with nested DatabaseConnectors but you'll have to do some additional work to support it. ZPatterns could definitely benefit from some ideas found in DatabaseAPI, primarily in the aspect of documenting API's and supporting better design contracts. For example, it would be nice for a Specialist to be able to define the API expected from its Racks, and a for an application framework to somehow define the API expected from the Specialists it will interact with. One could of course use the existing DatabaseAPI product to do these things, but the integration would be less than smooth, since you'd have to make the Specialist ask the Racks for their DatabaseConnectors, or else have a Rack class that delegated to a DatabaseConnector, or something like that. Anyway, I'm going to have to give these possibilities some more thought.