[
https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876015#action_12876015
]
Bruno Busco commented on OFBIZ-3373:
------------------------------------
Adrian,
a pattern that I have seen to be very powerful is to have a *unique* reference
page for each "topic" and have this improved as long as new features come
available on the system.
The new feature can become available installing new components but the user
should not know if a new feature is contained in a new component or in the old
component that has been changed.
I mean, coming to the profile page example,
the system user should only now that whatever is related to the party profile
is in a certain page, say Party->Profile.
Then if he is logged into a system where the only thing that is possible to do
is to change the user name and password he will find only these UI elements.
If, in the system, the party profile has more parameters becouse more business
components are installed than the party profile page UI should grow up allowing
all the available options and controls.
Using the ofbiz standard extension mechanism forces the user to change the
screen, or the application where to go as long as new components (with new
screens) are installed on the system.
Another example could be a unique "Settings" page where all settings for all
installed components are added.
When we introduced the Portal system we already did a step in this direction.
Right now, if a PortalPage is available in a "base" component, a newly
installed component can add, to that PortalPage, one or more Portlets defined
by itself.
This would allow a central define "Party Profile" or a "Settings" page to be
added with "dinamically" elements Portlets and Menus.
> 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.
