Not sure why my 1st post didn't get through. So reposting again..
Hi all, Good discussion so far. I am in favour of having a proper solution from start rather than a stopgap. Propose something similar to what Nicolas mentioned but making use of a fragment-type plugin framework like https://pf4j.org/. The idea is for the fragment-type plugins to be located within framework or plugins, and loaded by a new OFBiz container. For now, this fragment-type plugin helps to extend a particular UI Menu Item. When fetching a menu for a page, OFBiz looks into the fragment-type plugins that are loaded and add any new menu items as required. Regards, James PS: Regarding the thread topic, I prefer trunk demo for framework. On 2018/08/23 09:19:02, Nicolas Malin <nicolas.ma...@nereide.fr> wrote: > 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. [...] > >
