[Zope-dev] ZPatterns: General Design Question

[Phillip J. Eby]

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.)