[TransWarp] Constraints on model attributes

[Roché Compaan]

* Phillip J. Eby <pje at telecommunity.com> [2003-07-29 13:36]:
> 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:

True. Eugh, please bear with me, at least my examples are not all
misses, I get in some hits too ...

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

And I know this, although it may seem hard to believe. It's just that I
forcefully applied the Zope 3 schema thing to PEAK without giving enough
thought to how it should integrate with peak.model. And maybe all the
things that were wrong with my first copy of the Zope 3 schema is also
wrong with the current Zope 3 schema implementation in that constraints
and type checking are all hosted by types.

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

With this we will be one ahead of Zope 3 schemas.

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

Sure, and this is in my mind something that will become very important
in the adoption of PEAK - it is very comforting to know that it has UML
and MOF as foundation.

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

Great. And this is also all I really need for now.

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

Those examples were misses :-(

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za