-
Notifications
You must be signed in to change notification settings - Fork 3
/
use_cases.txt
156 lines (110 loc) · 6.26 KB
/
use_cases.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
* Different types of actions need to group together so they
conflict/override. Currently uses group_key method, renamed to
group_class for clarity. (Stick to this, as class is needed to sort
actions by dependency) (done)
* An action has an identifier for conflicts and overrides. Prefixed by
group key so we don't need to distinguish between actions in
different groups.(done)
* Extra discriminator list to make more conflicts happen. (done)
* Generate sub-actions instead of performing things directly. This is
done in prepare right now. (done)
* Directive abbreviations. (done)
* Abbreviated directives should have correct frame info for error
reporting. (done)
* Do checks on input parameters depending on what object is being
decorated (class versus function). Done in prepare, such as for path
directive. Should now move it into perform and raise errors if
things are wrong. Check on error reporting. (done)
* Dependencies between actions. (done)
* Subclasses of App can have new directives through the directive
directive (done)
* Prepare now only works one level deep: you can't implement a
directive as multiple actions which then in turn are actually other
actions. This has been fixed with Composite actions (done)
* Not use Venusian: a directive should register with the configuration
system (or better: the App) immediately upon import as it's easier to
explain. (done)
* We have some use cases where we'd like to execute some code after
all directives of a particular kind are done executing. This way we
could initialize the predicates for all external predicates
functions, for instance. (done)
* Have line number information for error reporting. (done)
* Apps could have multiple independent registries (or at least
registries APIs; many will build on the reg registry). Perhaps
actions can somehow declare which registry APIs they concern
themselves with. This way we could avoid mixing a lot of registry
mixins into a larger registry. (done)
* The config object should get the configurables explicitly. Or apps?
And then allow a commit. (done)
* rename to something else as Confidant as now on PyPI. Now dectate. (done)
* Sometimes during prepare it'd be useful to have access to the registry. But
since prepare is gone, not relevant anymore. (done)
* separate "configurations" object from configurable. (done)
* there's also an implicit list of configurables kept globally (done)
* Directive logging. (done)
* The normal conflict detection will report correctly that there's
a conflict if a module is imported twice. (done)
* should we store the *directives* on the configurable instead of the
actions to prevent any user code execution that can do too much? (done)
* but if a module is imported twice and a variable is increased upon
import that causes a non-conflict, a ConflictError won't be raised...
How contrived is that scenario? Could happen if you generate information
dynamically. This is now documented. (done)
* Ensure that morepath directives get registered before we start using them
in imports. Appears to be not a problem. (done)
* Directives have documentation that shows up in the sphinx docs (done)
* Implement scanning using recursive import. Done in Morepath using
importscan module. (done)
* Support configuration isolation: re-run configuration multiple times.
(done)
* Determine that two toplevel directives are actually the same one by
looking at line number information. Not done: we rely on a different
mechanism, conflict detection, to detect this now. this is documented.
(done)
* Refuse to support classmethod & staticmethod? Or refuse to support
methods? Conclusion: no classmethod, do support staticmethod. (done)
* the implicit list of global configurables can be reset for testing
purposes. Conclusion: don't allow this as it's useless for testing. (done)
* is it possible to set up the registries before the action group is
executed? Maybe not, as action group could still contain multiple
types of action. Unless we make `config` behave like `before` and
`after`. Or should we simply set up *all* registries, including
those for directives we never encountered? Should we also do before/after
for those registries without content? Conclusion: we set up the
registries for all action groups, and only action group main class
has a config. (done)
* should also do the above for action classes defined by base classes
and not used. (done)
* Configure logger by directive directive? This is now done in the App
base class with logger_name. (done)
* refactor so that action groups are set up *before* the rest of the
commit, so we don't have to create action groups just in time while
going through actions. Base it off the action groups we have
registered. an action group has a before, after and a config.
there's a shortcut way to register an action without an action
group, but an action with both an action group *and* shortcut
methods is an error. (done)
* the action_classes in setup_config should be sorted so that behavior
is consistent even if registries are set up inconsistently. (done)
* handle TypeError if action_factory is called with wrong parameters. (done)
* write a test for TypeError handling. (done)
* Registry dependencies:
a registry can be initialized with another registry as the constructor.
if the registry is listed it will be used. the other registry must
be listed in the config *or* be initialized by one of the depends.
{
'template_engine_registry': TemplateEngineRegistry, ('settings',)
}
Now implemented as factory_arguments. (done)
* rethink the way action groups work; right now they're by action
class, but the implementation gets confusing as we have the true
action class used to do the config setup and also the action group
class used for before/after. Either use the action group class for
everything, including config setup, or use another mechanism for
grouping. Done: now the action group is in charge of before, after,
config. (done)
* group_class for a group_class should be an error. (done)
* if a group_class class defines before or after or config, that should
be an error. But subclassing it is okay. (done)
* Deal properly with an action or composite that has no
__init__. Error. Fixed by providing a base __init__.(done)