core.bones.treenode

TreeNodeBone is a subclass of RelationalBone specifically designed to represent an intermediate node in a tree-like data structure. It provides a way to define hierarchical relationships between entities in a ViUR application.

The TreeNodeBone is of type “relational.tree.node”, which distinguishes it from other RelationalBone subclasses.

Module Contents

Classes

TreeNodeBone

TreeNodeBone is a subclass of RelationalBone specifically designed to represent an intermediate node in a tree-like
class core.bones.treenode.TreeNodeBone(*, consistency=RelationalConsistency.Ignore, format='$(dest.name)', kind=None, module=None, parentKeys={'name'}, refKeys={'name'}, updateLevel=RelationalUpdateLevel.Always, using=None, **kwargs)

Bases: viur.core.bones.relational.RelationalBone

TreeNodeBone is a subclass of RelationalBone specifically designed to represent an intermediate node in a tree-like data structure. It provides a way to define hierarchical relationships between entities in a ViUR application.

The TreeNodeBone is of type “relational.tree.node”, which distinguishes it from other RelationalBone subclasses.

Initialize a new RelationalBone.

Parameters:

  • kind (str) – KindName of the referenced property.

  • module (Optional[str]) – Name of the module which should be used to select entities of kind “type”. If not set, the value of “type” will be used (the kindName must match the moduleName)

  • refKeys (Optional[Iterable[str]]) – An iterable of properties to include from the referenced property. These properties will be available in the template without having to fetch the referenced property. Filtering is also only possible by properties named here!

  • parentKeys (Optional[Iterable[str]]) – An iterable of properties from the current skeleton to include. If mixing filtering by relational properties and properties of the class itself, these must be named here.

  • multiple – If True, allow referencing multiple Elements of the given class. (Eg. n:n-relation). Otherwise its n:1, (you can only select exactly one). It’s possible to use a unique constraint on this bone, allowing for at-most-1:1 or at-most-1:n relations. Instead of true, it’s also possible to use a :class:MultipleConstraints instead.

  • format (str) –

    Hint for the frontend how to display such an relation. This is now a python expression evaluated by safeeval on the client side. The following values will be passed to the expression

    param value:

    The value to display. This will be always a dict (= a single value) - even if the relation is multiple (in which case the expression is evaluated once per referenced entity)

    param structure:

    The structure of the skeleton this bone is part of as a dictionary as it’s transferred to the fronted by the admin/vi-render.

    param language:

    The current language used by the frontend in ISO2 code (eg. “de”). This will be always set, even if the project did not enable the multi-language feature.

  • updateLevel (RelationalUpdateLevel) –

    Indicates how ViUR should keep the values copied from the referenced entity into our entity up to date. If this bone is indexed, it’s recommended to leave this set to RelationalUpdateLevel.Always, as filtering/sorting by this bone will produce stale results.

    param RelationalUpdateLevel.Always:

    always update refkeys (old behavior). If the referenced entity is edited, ViUR will update this entity also (after a small delay, as these updates happen deferred)

    param RelationalUpdateLevel.OnRebuildSearchIndex:

    update refKeys only on rebuildSearchIndex. If the referenced entity changes, this entity will remain unchanged (this RelationalBone will still have the old values), but it can be updated by either by editing this entity or running a rebuildSearchIndex over our kind.

    param RelationalUpdateLevel.OnValueAssignment:

    update only if explicitly set. A rebuildSearchIndex will not trigger an update, this bone has to be explicitly modified (in an edit) to have it’s values updated

  • consistency (RelationalConsistency) –

    Can be used to implement SQL-like constrains on this relation.

    param RelationalConsistency.Ignore:

    If the referenced entity gets deleted, this bone will not change. It will still reflect the old values. This will be even be preserved over edits, however if that referenced value is once deleted by the user (assigning a different value to this bone or removing that value of the list of relations if we are multiple) there’s no way of restoring it

    param RelationalConsistency.PreventDeletion:

    Will prevent deleting the referenced entity as long as it’s selected in this bone (calling skel.delete() on the referenced entity will raise errors.Locked). It’s still (technically) possible to remove the underlying datastore entity using db.Delete manually, but this must not be used on a skeleton object as it will leave a whole bunch of references in a stale state.

    param RelationalConsistency.SetNull:

    Will set this bone to None (or remove the relation from the list in case we are multiple) when the referenced entity is deleted.

    param RelationalConsistency.CascadeDeletion:

    (Dangerous!) Will delete this entity when the referenced entity is deleted. Warning: Unlike relational updates this will cascade. If Entity A references B with CascadeDeletion set, and B references C also with CascadeDeletion; if C gets deleted, both B and A will be deleted as well.

  • using (Optional[viur.core.skeleton.RelSkel]) –

type = 'relational.tree.node'