Alternative "classic" navigation api?

[hugetim]

I think I'd like to be able to put all the navigation configuration in one place, in the Main (or startup) module. Then the navigation module needn't even be imported in the content forms. Rather, everything could be configured in one place, which could look like:

from anvil_extras import navigation
from ...Components import Components
from ...MessagingDemo import MessagingDemo

menu = [
    dict(text="Components", name="components", form=Components, title="Component Demos"),
    dict(text="Messaging", name="messaging", form=MessagingDemo, title="Publish/Subscribe Messaging"),
]

class Main(MainTemplate):
    def __init__(self, **properties):
        navigation.build_menu(self.menu_panel, menu)

Then when I want to add a new content Form to the menu, I need only make changes here (importing the Form and adding the menu specification dict). For one thing, this approach eliminates to need to make sure a 'target' key matches the 'name' key in a separate module.

[meatballs]

If we added this, I'd prefer to do so without making a breaking change.

I suppose we could check whether the 'target' is a string or form class and handle it differently in each case.

[meatballs]

I suppose my main objection to this is that it introduces coupling between forms. The current API consciously avoids such coupling.

As long as it's an option in addition to the existing, with decent docs and a warning about why coupling is bad for you (current Mrs. Campbell excepted, obviously), I'm OK with it.

[meatballs]

And my apologies that it's taken a while to crystallise those thoughts.

[hugetim]

I was only imagining it as an option in addition to the existing. But I don't yet understand your coupling concern well enough to explain it in the docs (though maybe you could just be the one to add the coupling warning part if that's easier than explaining to me here--I've only become aware of the concept of coupling in the past six months or so, honestly). If the menu were instead defined in the startup module, as below, would that alleviate the issue?

from anvil import open_form
from .Main import Main
from .Components import Components
from .MessagingDemo import MessagingDemo

menu = [
    dict(text="Components", name="components", form=Components, title="Component Demos"),
    dict(text="Messaging", name="messaging", form=MessagingDemo, title="Publish/Subscribe Messaging"),
]

open_form(Main(menu))

from ._anvil_designer import MainTemplate
from anvil_extras import navigation

class Main(MainTemplate):
    def __init__(self, menu, **properties):
        # Set Form properties and Data Bindings.
        navigation.build_menu(self.menu_panel, menu)
        self.init_components(**properties)

[meatballs]

How about...

If 'target' is a string, behave as now. But, if it's a class, instantiate it and use the instance.

[meatballs]

Probably also register the class with its name as the key.

[meatballs]

Actually, this is almost possible now. We could make name an optional parameter on the register function. If not passed, it uses the class name.

You then call register as a function in your startup module and can then build the menu anywhere.

[meatballs]

Right now, you'd still have to pass a name, but you could definitely register classes in your startup module instead of using a decorator and build your menu there too, if you wish.

[meatballs]

Eg

from anvil_extras import navigation
from ...Components import Components
from ...MessagingDemo import MessagingDemo

navigation.register(Components, name="components") 
navigation.register(MessagingDemo, name="messaging_demo") 

menu = [
    dict(text="Components", name="components", target="components" , title="Component Demos"),
    dict(text="Messaging", name="messaging", target="messaging_demo" , title="Publish/Subscribe Messaging"),
]

class Main(MainTemplate):
    def __init__(self, **properties):
		navigation.build_menu(self.menu_panel,menu)

(sorry, on my phone, so that's a bit of a mess)

[hugetim]

Ok, thanks! Yeah, I'm kicking myself for not seeing that that was already possible.

I still like this idea as a convenience, though:

If 'target' is a string, behave as now. But, if it's a class, instantiate it and use the instance.

I could take a crack at a pull request sometime (which sounds pretty simple), though it might not be for a while. The day job is has abruptly switched to busy again, starting today.