Rev 73e450b1 defines a new, *unused*, top-level, register_provider function
in nested_splitter.py.
No code uses this function yet, and nothing else changed. It is there only
for your comments.
As I write this, I think this function should be called register_class
instead of register_provider, for two, no three, reasons:
1. To reduce confusion with NestedSplitter.register_provider.
2. To indicate that it is a class (and not an instance) being registered.
3. To relegate the whole notion of Provider classes to the internals of
free_layout and nested_splitter.
So from here on I'll talk about *register_class* when talking about the
present *register_provider* function.
*Advantages*
There are several advantages to using register_class rather than defining
various MyProvider classes:
1. The Provider classes are pretty confusing. They expose a lot of the
free_layout machinery. In fact, their real purpose is to execute this code:
splitter = c.free_layout.get_top_splitter()
# Careful: we could be unit testing.
if splitter:
splitter.register_provider(self)
This gets done in the ctor for each Provider class. Imo, a call to:
nested_splitter.register_class(my_class, c, provider)
more clearly indicates what is actually happening. And what *is* happening
is that the free_layout class is being told how to instantiate my_class,
namely by calling provider(c).
Furthermore, these calls to nested_splitter.register_provider will happen
where (at present) the various MyProvider classes are instantiated. In
LeoPlugins.leo, this only happens in onCreate methods.
Imo, it is *much* clearer to call nested_splitter.register_class(...) in
these onCreate methods than to instantiate, what is, in effect, a helper
class which happens to call NestedSplitter.register_provider as a side
effect.
*Theory*
Here is the top level of register_class, again named register_provider at
present. The @others defines the InternalProvider class.
def register_class(a_class, c, provider, ns_do_context=None):
'''
A top-level function that registers a provider for use by the
NestedSplitter action menu.
a_class: The class (not an instance) being registered.
c: The Commander of the class being registered.
provider: A function f(c) returning a new instance of a_class.
ns_do_context: An optional predicate pred(id_)
if id_ == a_class.__class__.__name__,
pred(id_) should "do something" and return True.
Otherwise, pred(id_) should return False.
'''
@others
splitter = c and c.free_layout.get_top_splitter()
if splitter:
splitter.register_provider(
InternalProvider(
a_class,
c,
provider,
ns_do_context))
I won't show the InternalProvider class here. The only problem I can with
InternalProvider see is that ns_provides always only returns a single
(self.id_, self.id_) tuple, where self.id_ = a_class.__class__.__name__. If
this ever became a problem, one or more keyword args could be added to
register_class.
Also, I don't find a single place in which ns_do_context is actually used.
There is complex code in the free_layout code that tests hasattr(obj,
'ns_do_context), but traces show it isn't used, at least the way I use Leo
;-)
Anyway, I would like your comments, Terry. This is only the first step in
simplifying various API's so that more people will be able to use all of
Leo's cool features.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
