At 02:42 PM 12/14/00 +0200, Roch'e Compaan wrote:
As part of a Customer Relationship Management system our company is developing, we have a Licenses specialist which manages product licenses. All license objects do not have the same attributes however. The various attributes relating to different licence types are not known attributes from the outset.
My first reaction to this is that I would use a different class for each type of license, and a rack in the specialist for each class. This would allow maximum behavioral flexibility, since each class can have its own methods for inputting or displaying data. However, if your application needs to have end-user (as opposed to integrator-user) definition of license types, then you need to add LicenseType to your domain model and create a specialist for it (possibly nested inside the Licenses specialist).
As I see it one can take two approaches to this: a) either add a single dictionary property for both license and licensetypes which holds user defined attributes or b) explicityly call manage_addProperty per instance to add properties.
Option "b" will make your application ZODB-dependent, since there is no way to map arbitrary attributes to an SQL database, for example. Option "a" is better, since a dictionary attribute can be handled with WITH/COMPUTEs and triggers, with a little work. There is also an option "c", which would be to model LicensePropertyDefinition and LicenseProperty objects in your domain model. This approach leads to a bit more work defining your model, as well as in setting up the specialists and their interactions, but the payoff is in better documentation of what your app is doing and easier re-mapping from one database type to another. Ty and I recently experienced something similar, in an application where we were using a dictionary attribute to represent something that was better modelled as a seperate object. The complexity of the associated SkinScript and DTML/Python/SQL methods went down after we bit the bullet and added a nested Specialist. (When a role in a domain model is only accessed from one other role, it is reasonable to nest that role's Specialist inside the other's, as it keeps the higher-level app namespace cleaner. Usually there is some clustering to domain models that puts a small number of supporting classes in a position to do this for each major class.)