[
https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876010#action_12876010
]
Adrian Crum commented on OFBIZ-3373:
------------------------------------
It seems to me we are going in the wrong direction here. From my perspective,
the party manager application should only contain screens for managing a party.
I've always had a problem with those links to other applications, and things
have grown worse recently with menus in the party manager for employment and
such - menu items that may not be applicable for that party. In the current
trunk there are 20 tabs on the view profile page, and most of those tabs
shouldn't be there. To summarize, too much external functionality is being
forced into the party manager application.
>From my perspective, it should be the other way around. The party manager
>application should have screens and services to manage a party - and nothing
>more. Other applications extend those screens and services for specific party
>roles. For instance, an order manager application would have a Find Customer
>or Find Supplier screen, and that screen would constrain the Find Party list
>to customers or suppliers. The application would ADD the Orders link to the
>list in the screen shot. In the Customer/Supplier view profile screen it would
>ADD the Tax Infos, Rates, Shopping Lists, Fin History, and Product Store Roles
>tabs to the menu.
In a similar way, a human resources application would extend the party profile
screen and add the Party Skills, Resumes, and Employment Applications tabs to
it.
Although the party manager is being used as an example here, I've seen the same
abuses/misuses done in other applications.
I don't mean to throw a wet blanket on this effort, I just think the end result
of this issue will encourage even more bad designs.
I haven't tried Scott's patch, but a cursory look at it gives me the impression
that applications can change the widget models on-the-fly. I don't think that
is a good idea. In the current implementation, a Freemarker template gets a
list of all mounted applications and creates a main navigation menu based on
the user's permissions. In other words, the list of all applications is
filtered down to the applications the user is permitted to use. Maybe I'm
missing something, but Scott's patch doesn't seem to duplicate that behavior.
I'm assuming each application menu item that is "injected" will have some kind
of permission checking tied to it.
Anyway, these are things that need to be discussed.
> Adding menu merging feature
> ---------------------------
>
> Key: OFBIZ-3373
> URL: https://issues.apache.org/jira/browse/OFBIZ-3373
> Project: OFBiz
> Issue Type: Wish
> Components: framework
> Reporter: Bruno Busco
> Priority: Minor
> Attachments: googlebase-inject.patch, injections.patch, links.jpg,
> partymenu.JPG
>
>
> Hi devs,
> while discussing in the ML about modules and framework separation I thought
> to this new feature that I would like to discuss here with you.
> We have now the possibility to extend a menu from one other. This is great in
> order to have an high level of code reuse and great consistency all over
> OFBiz.
> I was thinking to a sort of "merges-to" property for the menu widget.
> This would allow a new module to specify an already exixting menu name (in
> the framework core or in a lower level module) that should be somewhat
> changed by the actual menu.
> For instance, in the attached image partymenu.jpg there is a a tipical use of
> this feature:
> in the party module there are lot of links that co to order application,
> account etc. Those menu link could be used defining a simple menu (say it
> partylinks_menu) in the party application that contains only party or
> framework related links (i.e. profile); additional components like order or
> accounting could define more menus that merges-to the partylinks_manu so that
> when the menu is rendered IN THE PARTY APPLICATION the new menu items added
> in the order and accounting applications are also rendered.
> This would allow us to dramatically reduce the component dependence and help
> us to have the framework-only distribution.
> To eventually implement this I think there should be an entity that defines
> such mergin menus and the menu rendered should lookup the entity to check if
> one or more merges to the actually rendering menu is defined.
> I would appreciate to hear from you if this idea can help.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
