I sent this privately to Terry by mistake. It should be public. On Sat, Mar 26, 2016 at 5:25 PM, Terry Brown <[email protected]> wrote:
> On Sat, 26 Mar 2016 13:06:23 -0500 > Terry Brown <[email protected]> wrote: > > what about renaming InternalProvider BaseProvider, making it > module level, and having people do: > > class MyProvider(BaseProvider): > my_id = "this_id_here" > def ns_provide(self, id_): > if id_ == self.my_id: > return heres_my_widget() > > c.free_layout.get_top_splitter().register_provider( > MyProvider(c, "Menu name", MyProvider.my_id)) > I thought of this too. Having slept on the problem, it seems that the simplest, clearest thing that could possibly work would be to make the following *completely optional* changes. Replace: class MyProvider: def __init__(self, c): boilerplate ... with: class MyProvider: ... free_layout.register_provide(MyProvider) In other words, the provider stays exactly the same, except that it's ctor goes away. In fact, in all the Provider classes in LeoPlugins.leo, the ctor is this: def __init__(self, c): self.c = c # Careful: we may be unit testing. if hasattr(c, 'free_layout'): splitter = c.free_layout.get_top_splitter() if splitter: splitter.register_provider(self) So the top-level free_layout.register_provider function would be just this: def register_provider(c, a_class): if c and hasattr(c, 'free_layout'): splitter = c.free_layout.get_top_splitter() if splitter: splitter.register_provider(a_class) Moving boilerplate code into register_provider should usually be clearer and simpler than defining a boilerplate ctor. But in truth, *everything stays exactly the same.* > To clarify the "if id_.startswith(self.my_id+':')" part, what happens is > that a provider tells nested_splitter that it provides something with > id "_foos_id", but when it's asked to provide one of those widgets, it > annotates the widget with ._ns_id == "_foos_id:color:green:flavor:lime" > and then when nested_splitter is loading a saved layout it actually > asks the list of providers to provide something with that id. > Cool. We'll want to keep this, and all the other machinery, *strictly *as it is. Feels like we're both just fiddling around with things that are > working, perhaps what's really lacking are clear docs. for the > nested_splitter system. > Yes. *Summary*I want free_layout.register_provider for the following reasons: 1. It changes *absolutely nothing* about the workings of free_layout.py. In particular, there is no need to define a base class. 2. It retains the provider terminology. I now understand why you prefer it to "factory". 3. It is *completely optional*. Private MyProvider classes that you or others may already be using can remain forever unchanged. No need for a git branch. 4. Having said this, replacing the ctor in MyProvider classes by a call to: free_layout.register_provider(MyProvider) has two advantages: A. It makes explicit the registration that used to happen as a side effect. B. It moves boilerplate code into free_layout.register_provider. In short, the proposed scheme is safe. I plan to make the proposed changes to the 5 classes in LeoPlugins.leo once you approve of this scheme. What do you think? Edward P.S. I'll remove the new code in nested_splitter immediately. EKR -- 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.
