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.
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. 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. On Wed, Aug 22, 2018 at 11:13 AM Julien NICOLAS <julien.nico...@nereide.fr> wrote: > > Hi all, > > My opinion is to hide the link instead of delete it. I don't know if we > have other link in this case but it could be important to keep it in > source code. It could be convenient to have it for replacement by the > good solution > > But in the same time, we need to think about inter-webapp connection. > How a menu from webapp A could be extended by webapp B without putting > code in webapp A. > > It could be interesting to have a new tool bar in product to manage > ecommerce when ecommerce is installed. If we have this kind of feature, > it could work as well for OOTB webapp like product and stock, party and > order, etc. > > Julien. > > > Le 21/08/2018 à 10:10, Jacques Le Roux a écrit : > > OK, that your and Michael's opinions. So you prefer NPEs in code than > > hiding them when necessary? > > > > What others think? > > > > Jacques > > > > > > Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit : > >> Again, hiding is not a solution and is correcting an error with another > >> error. > >> > >> -1 > >> > >> On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux > >> <jacques.le.r...@les7arts.com> > >> wrote: > >> > >>> See my answer in the Jira, we can't tolerate NPEs, they are already > >>> there > >>> for too long > >>> > >>> Being smart is cool, being smart and clean is better ;) > >>> > >>> Jacques > >>> > >>> > >>> Le 21/08/2018 à 08:57, Michael Brohl a écrit : > >>>> We should neither simply remove those links nor should we have > >>>> anything > >>> hard coded. > >>>> Let's look for a smarter solution. No need to hurry, better take some > >>> time to implement something sustainable. > >>>> Regards, > >>>> > >>>> Michael Brohl > >>>> ecomify GmbH > >>>> www.ecomify.de > >>>> > >>>> > >>>> Am 21.08.18 um 07:00 schrieb Jacques Le Roux: > >>>>> Of course, but I like to be able to get from the backend to the > >>> frontend when it's possible. > >>>>> I don't see any troubles keeping them once it's handled that way, but > >>> theoretical ones . > >>>>> Of course if the community prefers to remove them it's far easier and > >>> was what I wanted to do initially before having this idea of hiding > >>> links > >>>>> Jacques > >>>>> > >>>>> > >>>>> Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit : > >>>>>> Simple, don't put any logic that points outwards from the framework. > >>> That > >>>>>> is sort of why we split repositories in the first place. > >>>>>> > >>>>>> On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux < > >>> jacques.le.r...@les7arts.com> > >>>>>> wrote: > >>>>>> > >>>>>>> Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit : > >>>>>>>> Makes sense. However, i note reading in the JIRA that "we can > >>>>>>>> simply > >>> hide > >>>>>>>> the button when the ecommerce component is not present". That > >>>>>>>> sounds > >>> like > >>>>>>>> logic that points outwards which is a bad design IMHO. > >>>>>>> I could not find a better way yet, I'm all ears for ideas. > >>>>>>> > >>>>>>>> Anyway, I think it is a reasonable step to take. +1 > >>>>>>> I attached a patch for today at OFBIZ-9241 > >>>>>>> > >>>>>>> Jacques > >>>>>>> > >>>>>>>> On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux < > >>>>>>> jacques.le.r...@les7arts.com> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> The proposition is in the title. > >>>>>>>>> > >>>>>>>>> With the changes I'm introducing with OFBIZ-9241 there will few > >>>>>>>>> differences in UI (and presence of js files) between the > >>>>>>>>> framework > >>> only > >>>>>>> and > >>>>>>>>> the > >>>>>>>>> framework+plugins > >>>>>>>>> > >>>>>>>>> I must add: > >>>>>>>>> > >>>>>>>>> * since the old is often no longer supported and a > >>>>>>>>> release of > >>> it is > >>>>>>>>> always available (today R13) for users. I think removing the old > >>> demo is > >>>>>>>>> maybe > >>>>>>>>> not a big deal. > >>>>>>>>> * I found several cases where people, new to OFBiz, > >>>>>>>>> considered > >>> OFBiz > >>>>>>> as > >>>>>>>>> what we call the framework, and were considering the plugins as > >>>>>>> optional. > >>>>>>>>> What do you think? > >>>>>>>>> > >>>>>>>>> Jacques > >>>>>>>>> > >>>>>>>>> > >>>> > >>> > > > > >
