2

Following Ordering menu items fed from multiple modules the question was raised to me, who is responsible for ordering and alignment of menu items in a modular application.

The previous link suggests that the module who offers the menu item is responsible for saying where it will be located ("at index n", "after module x", "before module y"). Multiple further resources propose a IMenuService where modules can register or remove their menu items, e.g. PRISM Framework.

But intuitively I would say that the main application should take the responsibility. Modules should not necessarily know other modules just to order their own menu item. Nor should the module in principle decide itself where it appears in the menu in a larger context. E.g. the logout menu item should have some offset to other items or a certain menu item gets a special color because it is consired important by the application at the moment.

So resulting from that consideration I thought how the main application (core) could handle this. But in this case the main application must have knowledge of the menu items and their concrete types. Thus, must newing up the items offered by the different modules or using the resolve method of the IOC container to differ between them resulting in a kind of service locator anti-pattern. (Constructor injection with n menu item dependencies seems not right to me either)

So I don't know if this is an opinion based question, but for sure a design question.

What would you propose as a solution or how is this scenario handled by other applications? What is the standard way of composing the menu?

Further information: I am currently developing a modular mobile application with Xamarin and Prism (with DryIOC) as the MVVM and IOC framework.

  • 1
    There's a larger picture here. A menu is just a UI element, and it's arguably not the most important (or modern) one. Many applications don't have menus (as UI elements) at all; they use different mechanisms for navigation. Prism navigation abstracts these concepts so that they can remain modular and pluggable, but nothing prevents you from doing it the old-fashioned way. – Robert Harvey Nov 3 '17 at 17:04
2

Have you considered that the menu itself is a standalone module? I have to admit I don’t know what you mean by “core” of the application in this context, so I don’t know if it needs to know about all the modules, but I can see how a menu could be a standalone module whose responsibility is to know how to order the display of the other modules and can send events into the core like “user selected module X” and so on.

  • By "core" I meant the base application project that is responsbible for startup, IOC container filling etc. Currently my GUI framework including menu structure resides in this base project. But sure, that could be outsourced to a seperate module, would be even cleaner. Do you think the events should be string based, so the menu module has no type-safety but is decoupled from other modules (besides implicite knowledge of the strings) or should the several modules offer an event argument type via API? – Creepin Nov 3 '17 at 18:37
  • I don’t know the details of your system but I would suggest that the modules in question have well-defined URLs that they provide as the destination when selected. That way the core and menu itself don’t need to know too much. – RibaldEddie Nov 3 '17 at 19:08
  • Yeah, that's what I meant by string based. These are kind of URLs. Thanks, I will try this event based approach. – Creepin Nov 3 '17 at 19:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.