I have just reviewed the links again, and the example provided by Jacques is to access the ecommerce product page from the product component as a menu item.
Honestly, I think for this example it should simply be deleted. It serves no substantial value to me: - I most likely will not use the standard ecommerce component - I can easily view all the products directly from the ecommerce component. There is no terrible need to access it from the product component. - It does not even make sense to access the product page from the product component. The purpose of the product component is to define and control products, not view their ecommerce pages, heck you might have them on an external system all together. Furthermore, I'm not sure we need another superman initiative in the widget system? The price to pay for this does not seem to be worth the added value, I would hardly call it a value but maybe I'm wrong? On Aug 24, 2018 9:55 AM, "Julien NICOLAS" <[email protected]> wrote: Hi Nicolas, With your proposal, I'm afraid that we can't simply add a new menu in an application from a plugin. Maybe it's another subject but it could be interesting to manage it in the same times. Technically I understand your proposal but it's difficult for me to understand the impact ^^ Julien. Le 23/08/2018 à 11:19, Nicolas Malin a écrit : > Hello > > This thread about a "simple" problem highlights the difficulty for a > plugin to extend the framework on different elements. Since many years > I search different solution to how surcharge correctly the framework > and it was not easy :) > > in line > > On 22/08/2018 18:52, Taher Alkhateeb wrote: >> Hi Julien, >> >> Good ideas, and this is a good start to try and tackle the problem. >> Whatever we do, we must not keep "ghosts" or things that are waiting >> for specific outside plugins. The framework should _never_ know >> anything about the outside. This is a fundamental architectural >> concept in any layered software system. > Absolutely right, I knew a ghost history with addons that changed > source code base to load plugin's specificsinstead of understandingwhy > we can't surcharge the framework :) >> I'm ready to help if needed, and I think there are many ways to fix >> this problem. As you said one way is to extend webapps, another is >> perhaps to optionally include freemarker templates that match a >> certain pattern if they exist. In other words, you provide a generic >> plugin-like mechanism for enhancing the system, but the direction is >> _always_ from the outside to the inside, and not the other way around. >> And that is what I mean with a root-cause analysis and solutions. > > Maybe I have two different solutions, based on theidea to usethemodel > pattern toload all plugin surcharge at the ofbiz start like services > and entities > * The first, load all screen engine modelsin memory at start, but I > fearthatit would be too expensive on memory (load unnecessary screens) > * The second, create an'extend model' who permit to surcharge all > screen engine model elements,andload it on ofbiz start and when we > load a model, we check on extend model if the element have surcharge > to apply just before settingit as immutable and put it in cache. > > example : > <extend-form location='component://party/widget/PartyForms.xm' > name='ViewPartyGroup'> > <field name="partyId" > > <hyperlink description="Goto my plugin with : ${parameters.partyId}" > target="/myplugin/control/viewprofile" target-type="inter-app" > target-window="blank_"> > <parameter param-name="partyId"/> > </hyperlink> > </field> > </extend-form> > > With this, we would have a plugin that can surcharge a screen, a form, > a menu without changingnothing in the framework, identify clearly what > change has been made and a failure support when the extend can't be > applied. > > Currently I didn't found a solution to surcharge ftl. > > If you feel that it's a good way to explore, I will start a new thread. > > Nicolas >> So I'm all for a generic solution, but not for hard-wiring any >> component or any link that is specific to a certain component. That is >> definitely a code smell and beats the entire purpose of splitting the >> repositories in the first place. [...] > >
