[TransWarp] Constraints on model attributes

[Phillip J. Eby]

At 09:41 AM 7/29/03 +0200, Roché Compaan wrote:

>The problem is that the sequence for the enumaration can be dynamically
>computed, so subclassing won't work eg.:
>
>class Customer(model.Element):
>
>     class Category(model.Attribute):
>         referencedType = Enumeration(values=func)
>
>where func returns a list of categories the user created in the app.

Then that's not an enumeration.  That should be:

class Category(model.Element):
      ...

class Customer(model.Element):

     class category(model.Attribute):
         referencedType = Category

The form widget for 'Customer.category' would need to find an appropriate 
DM for objects of type Category, and find the category designated by the key.

Enumerations are for values that are fixed in code.  What you're looking 
for here is just an object reference.

Now, in order for this to work well, there may need to be more metadata on 
the feature or the type, like what field of the referenced type should be 
used as a key, and what should be used as a title (e.g. for dropdown boxes).


> > I suppose I can imagine there being certain types that you don't want to
> > call out explicitly because they repeat a lot (e.g. bounded strings), but
> > I'd rather address such items on a case-by-case basis with e.g. functions
> > to create a new type on the fly.  Hm.  I suppose you could always create
> > constraints as IType/ITypeInfo implementations to wrap existing types, 
> e.g.:
> >
> > class DroneName(Enumeration):
> >     John = Mary = Pete = model.enum()
> >
> > class Drone(model.Element):
> >     referencedType = MinMaxLen(DroneName, max_length=4)
>
>This shows promise. Or MinMaxLen could be a type factory, then no
>wrapping is needed?

I suppose you could have it create a dynamic subclass.


>I just want to make it as simple as possible for somebody using these
>types. It should be as trivial as saying varchar[10] in SQL. Subclassing
>shouldn't be required for simple constraints:
>
>     class MemberPassword(model.Attribute):
>         referencedType = Password(min_length=4)
>
>     class Age(model.Attribute):
>         referencedType = Integer(min=18)
>
>     class Gender(model.Attribute):
>         referencedType = Text(values=['male','female'])
>
>     class SomeCategory(model.Attribute):
>         referencedType = Enumeration(values=func_returning_categories)

peak.model is intended for modelling structures defined using UML or MOF 
metamodels.  IOW, it was really intended for generating code from such 
models, and if you define an enumeration like Gender in a UML model, it's 
going to have a class.

I don't see a problem with creating class factories along the lines of your 
Password and Integer types above, or even for 
String(maxLength=whatever).  But enumerations (e.g. gender) and object 
references (e.g. categories) have no business being hidden inside another 
object's definition.  That's just not a good design.  I'd much rather see 
code to generate modules from UML for this, than try to make it "simple" to 
do things the wrong way.