0
|
1 |
Rule
|
|
2 |
====
|
|
3 |
|
|
4 |
A Configuration can contain rule's, which can be aplied to the :class:`~cone.public.api.Configuration`
|
|
5 |
:class:`~cone.public.api.Feature`'s. In ConE a single rule will create an instance of :class:`~cone.public.plugin.Relation`.
|
|
6 |
|
|
7 |
The textual format of a rules is always of form:
|
|
8 |
::
|
|
9 |
|
|
10 |
<left side> relation_name <right side>.
|
|
11 |
|
|
12 |
The rule dialect
|
|
13 |
----------------
|
|
14 |
|
|
15 |
The features are accessed in the left and right side of the rule with the default :class:`~cone.public.api.View` of the :class:`~cone.public.api.Configuration`.
|
|
16 |
Basically ConE will get the default_view and use the :class:`~cone.public.api.ObjectContainer` member access to retrieve the feature.
|
|
17 |
There are few special characters that are converted to function calls in the rule transformation.
|
|
18 |
|
|
19 |
* ``*`` => refers to all immediate childer of this node, which is transformed to method call :meth:`cone.public.api.ObjectContainer.__objects__`
|
|
20 |
* ``**`` => refers to all childer of this node, which is transformed to method call :meth:`cone.public.api.ObjectContainer.__traverse__`
|
|
21 |
|
|
22 |
Both sides of the rule are something that the :class:`~cone.public.plugin.Relation` will somehow evaluate. How the left
|
|
23 |
side and right side are evaluated, is basically specific to the implementation of the :meth:`~cone.public.plugin.Relation.execute`
|
|
24 |
method of the :class:`~cone.public.plugin.Relation`. However certain basic evaluation rules apply to all :class:`~cone.public.plugin.Relation` objects.
|
|
25 |
|
|
26 |
When a feature is referred, ConE will try to return the value of the feature.
|
|
27 |
Then the Relation tries to evaluate if the given feature is bound and evaluates as True.
|
|
28 |
|
|
29 |
So for example referring to a feature.
|
|
30 |
|
|
31 |
``group.fea1`` is the same as writing ``group.fea1==True`` for a boolean feature.
|
|
32 |
``group.intfea1`` is the same as writing ``group.fea1!=0`` for a integer feature.
|
|
33 |
|
|
34 |
If a feature is unbound, trying to access its value will raise UnboundError.
|
|
35 |
|
|
36 |
Boolean logic in rules
|
|
37 |
----------------------
|
|
38 |
|
|
39 |
Both left and right side of the rule can contain normal boolean algebra that is utilized in the evaluation. This uses
|
|
40 |
default python syntax for boolean logic, with keywords *and*, *or*, *not*.
|
|
41 |
|
|
42 |
Example of boolean logic
|
|
43 |
^^^^^^^^^^^^^^^^^^^^^^^^
|
|
44 |
::
|
|
45 |
a.b and c.d=10 depends (not a.b.x=10 or a.b.x=0)
|
|
46 |
|
|
47 |
|
|
48 |
|
|
49 |
|
|
50 |
Rules with different multiplicity
|
|
51 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
52 |
The above mechanism enables that the rules can define relations with different multiplicity.
|
|
53 |
|
|
54 |
* one-to-one
|
|
55 |
|
|
56 |
* e.g. A depends B
|
|
57 |
|
|
58 |
* one-to-many
|
|
59 |
|
|
60 |
* e.g. A depends B.*, which is basically the same as wrinting A depends (B.child1 and B.child2 and ..)
|
|
61 |
* e.g. A depends B and C
|
|
62 |
|
|
63 |
* many-to-one
|
|
64 |
|
|
65 |
* e.g. A.* depends B
|
|
66 |
|
|
67 |
* many-to-many
|
|
68 |
|
|
69 |
* e.g. A.* depends B.*
|
|
70 |
|
|
71 |
Examples
|
|
72 |
--------
|
|
73 |
|
|
74 |
* A.B.C requires A.B.D
|
|
75 |
* fea.group.* requires fea.group
|
|
76 |
* wlan.setting maps voip.setting=10
|