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