I was actually thinking to Birt as an example of this behavior: but in the future we may add other special purpose applications that need to override applications screens (in fact overriding screens and other artifacts to specialize them is a best practice in OFBiz) and the problem will happen again if we keep them all enabled.
Jacopo On Thu, Nov 19, 2015 at 11:45 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Could we list, apart the well known Birt issue, special components which > are overriding main applications? > > Then depending on cases we could be more surgical... > > Jacques > > > Le 19/11/2015 09:46, Jacopo Cappellato a écrit : > >> I agree with Taher when he says that we should strive to move small steps >> in the direction of having a lean lightweight framework with pluggable >> components. >> But I think that Nicolas' proposal is actually one of these steps. >> The fact that currently some of our specialized components are overriding >> the more generic behavior of other components (e.g. the ones under >> "applications") is a problem that we have to fix asap. >> Otherwise the default demo of OFBiz will only showcase the more >> specialized >> behaviors; for example, if tomorrow we will add a new special purpose >> component for a niche industry, that will override the application screens >> with industry specific ones from that day on all OFBiz users that will >> download and run OFBiz will have the impression that OFBiz was designed >> for >> one specific industry only. >> Nicolas' proposal addresses this issue and still leaves the ability to the >> interested users to manually enable the components they need. >> >> Jacopo >> >> On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb < >> slidingfilame...@gmail.com >> >>> wrote: >>> Hi Nicolas, >>> >>> I think If your finger hurts you don't cut it off. The project has too >>> many >>> pages, documentations, email threads and time dedicated to the special >>> purpose components. They existed for a long, long time in the history of >>> OFBiz. >>> >>> Some attempts were made in the past to reduce the size of the framework >>> and >>> release 13.07 is a prime example of these attempts which failed IMHO. >>> This >>> is a reason why, for example, a rewrite of the framework is being >>> discussed >>> in the community. >>> >>> I would suggest to you that to get really lean and clean, we need to work >>> on the root of the problem which is the design of the framework and its >>> architecture. We need a _plugin_ implementation that achieves _loose >>> coupling_ of the components in a way that sustains the quality of the >>> code >>> while at the same time allowing a small framework core to thrive. Take a >>> look at this thread <http://ofbiz.markmail.org/thread/7bipnq3ffoteliff> >>> in >>> which we discussed this issue and suggested one of several strategies. >>> There are other threads which I cannot recall at the moment. >>> >>> For the record, I totally agree with keeping a small core and a lean >>> framework, It's how we get there that I'm worried about and I would >>> suggest >>> to you that we do this in a well thought out and gradual process. >>> >>> My 2 cents >>> >>> Taher Alkhateeb >>> >>> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin < >>> nicolas.ma...@nereide.fr> >>> wrote: >>> >>> Le 10/11/2015 05:54, slidingfilame...@gmail.com a écrit : >>>> >>>> This topic was heavily discussed in the past and I think a solution like >>>>> turning off the components is very quick indeed but not ideal. >>>>> >>>>> Completely, I'm sure a better ideal exist but difficult to reach. >>>> >>>> A second step, easy to reach would be enable a specialpurpose directly >>>> by >>>> an ant target : >>>> $ ant load-component -D"component=ecommerce" load-demo start >>>> or >>>> $ ant load-component -D"components=ecommerce projectmgr myportal" >>>> load-demo start >>>> >>>> This help beginner through easy command line to copy/past from >>>> documentation or expert by scripting to configure ofbiz. >>>> >>>> Nicolas >>>> >>>> >>>>
