Todo
intro
Todo
strict, duck, etc.
If descent_validators is defined, these validators will be run first, before member elements are validated.
If validators is defined, these validators will be run after member elements are validated.
Bases: flatland.schema.containers.Mapping, dict
A mapping Container with named members.
One of ‘strict’, ‘subset’ or ‘duck’. Default ‘subset’.
See set() Policy
Todo
doc of()
Return an element initialized with an object’s attributes.
Parameters: |
|
---|
include and omit are mutually exclusive.
This is a convenience constructor for set_by_object():
element = cls(**kw)
element.set_by_object(obj, include, omit, rename)
Todo
doc set()
Set fields with an object’s attributes.
Parameters: |
|
---|
include and omit are mutually exclusive.
Sets fields on self, using as many attributes as possible from obj. Object attributes that do not correspond to field names are ignored.
Mapping instances have two corresponding methods useful for round-tripping values in and out of your domain objects.
update_object() performs the inverse of set_object(), and slice() is useful for constructing new objects.
>>> user = User('biff', 'secret')
>>> form = UserForm()
>>> form.set_by_object(user)
>>> form['login'].value
u'biff'
>>> form['password'] = u'new-password'
>>> form.update_object(user, omit=['verify_password'])
>>> user.password
u'new-password'
>>> user_keywords = form.slice(omit=['verify_password'], key=str)
>>> sorted(user_keywords.keys())
['login', 'password']
>>> new_user = User(**user_keywords)
Update an object’s attributes using the element’s values.
Produces a slice() using include, omit, rename and key, and sets the selected attributes on obj using setattr.
Returns: | nothing. obj is modified directly. |
---|
Return a dict containing a subset of the element’s values.
Bases: flatland.schema.containers.Dict
A Mapping which may contain a subset of the schema’s allowed keys.
This differs from Dict in that new instances are not created with empty values for all possible keys. In addition, mutating operations are allowed so long as the operations operate within the schema. For example, you may pop() and del members of the mapping.
The subset of fields to autovivify on instantiation.
May be None or 'required'. If None, mappings will be created empty and mutation operations are unrestricted within the bounds of the field_schema. If required, fields with optional of False will always be present after instantiation, and attempts to remove them from the mapping with del and friends will raise TypeError.