[TransWarp] Constraints on model attributes

[Roché Compaan]

* Phillip J. Eby <pje at telecommunity.com> [2003-07-28 03:37]:
> At 10:33 PM 7/27/03 +0200, Roché Compaan wrote:
> 
> >I started out following the pattern you describe above but as I went
> >along I realised some attributes belong in the feature definition and
> >not in the type definition.
> 
> Judging by your attachment, I'd have to say we disagree quite a bit on 
> which is which.  IMO, your Container, Iterable, Orderable, Enumerable, 
> Bool, Int, and so on are all *types* -- even MinMaxLen.  These are all 
> things that are entirely independent of a structural feature.  (By the way, 
> peak.model offers a built-in enumeration type, as well.)

No we don't disagree, it's just that it felt unnatural for me at first
to put so much metadata in the type and the existing PEAK types were
pretty lean and mean.

> >I agree with you though, constraints that
> >have bearing on the type should be defined on the feature type. I
> >rewrote Zope3's schema fields PEAK style to see how well it will work in
> >PEAK. The kludgy part at the moment is validating type constraints, but
> >I think this can be resolved by following the pattern you mention above.
> 
> I see no value in your Field subclass.  It adds nothing over using 
> mdl_normalize method on types to do validation.

Except for ensuring that all model.Attributes have title, description
and readonly attributes and provide a hook for constraints. It is clear
to me now that these attributes can be put in a separate feature base
and types should stay types.

> I'm wondering if perhaps the issue here is that you're assuming that a 
> peak.model Type must be a class that's used for the values.

I realize that. My implementation ended up convoluted because it wasn't
clear to me how one can validate object-level constraints *and* type
constraints when setting the value for a feature so it all ended up in
_validate.

> That is not the case; a Type exists to supply metadata (such as a
> parsing syntax), type conversion, coercion, and constraints.  Thus, I
> would render virtually all of your Attribute subclasses as Type
> subclasses instead, and use mdl_normalize methods where you have
> _validate methods.

Don't you want to give some examples of how syntax is used for
conversion. What is happening here:

        syntax = feature.syntax

        if syntax is None:
            syntax = getattr(feature.typeObject, 'mdl_syntax', None)

        if syntax is None:
            syntax = fmtparse.Conversion(
                converter = feature.fromString,
                formatter = feature.toString,
                defaultValue = feature._defaultValue,
                canBeEmpty = feature.canBeEmpty
            )

> I might keep the _onLink() methods in a convenient feature base if I wanted 
> to be able to implement constraints,

Yes, like I mentioned above.

> but I think I'd rather focus attention on *object*-level constraints,
> and perhaps an object-level validation.
>
> Indeed, I wonder if maybe peak.model should offer an object-level 
> validation hook, that gets called before an object's state can be flushed 
> to storage.  If this hook were also callable by UI frameworks, they could 
> simply set all values as desired, call the validation hook to get a list of 
> problems, and roll back the transaction.

In addition to validation hooks on structural features?

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