[PEAK] A quick UI API sketch
Phillip J. Eby
pje at telecommunity.com
Wed Nov 7 20:43:29 EST 2007
This should be somewhat self-explanatory in the light of the previous
post, but some non-obvious points are added below...
currentDate = ...
_(u'Preview Date'), _(u'The day to view in the preview area'),
_(u'Next Day'), _(u'Move forward a day'),
_(u'Navigation'), _(u'Navigation menu for the preview area'),
items = [previousDay, nextDay, ...],
This is sketching a scope with a set of scope-defined features and
presentation options. Specifically, it's all being done inside the
original scope class. For a plugin to extend these features, it
would need to define an AddOn to attach to the scope.
The idea for object references is to use objects as keys or
identifies to uniquely designate a feature. This might be a
CellProperty or an unbound method (i.e. function linked to a class),
for example. Technically, these objects can be *converted* into keys
of some sort; we won't want to use them directly for various ugly
reasons relating to inheritance and overriding. But as long as the
key can be generated *from* the object, we can use the objects in the
API. A plugin can import the scope it wants to extend, for example,
and refer to e.g. ``PreviewScope.currentDate`` in order to look
something up by that key.
The idea with the various things like ``ui.Text[foo]`` is that
feature and CA types can be subscripted by an object to return a
registration factory for an instance of that type. You then call the
factory with whatever arguments are relevant, in order to register
construction data, that will be used at Scope creation time to add
the actual feature or CA instances.
There's still a lot to flesh out here, but this seems like a step in
the right direction. Notice, by the way, that CA groupings are done
via a path string key instead of an object key; this makes it
somewhat more practical to have plugins contribute to a shared menu
that neither one defined.
More information about the PEAK