Hi all, IMO, it may be better to improve upon ExampleExt to show how to extend/override the entities, services, screens, forms, events from Example component. This will help developers to implement OFBiz solutions correctly and make future upgrades possible.
Regards, James Yong On 2018-01-09 18:44, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > Hi Taher, All, > > Scott made another good point on party for the reason of the existence of > securityext > > I'll try to summarise where we are so far: > > * Both entityext and securityext have intrinsic value. They could be > improved but a priori not removed and then specific Jiras should be created. > * exampleext could me merged with example or simply removed (to be > verified). In both cases, some documentation about what it (pitifully I must > say) > tries to show should be created, preferably as a README.md in example > component. A specific ticket should be created for that > > Agreed? > > Jacques > > > Le 08/01/2018 à 19:14, Taher Alkhateeb a écrit : > > I stand corrected, Scott made a very good point regarding entityext > > that I did not pay enough attention to. Perhaps the name is misleading > > though, entityext means an enhancement or extension of the > > capabilities of the entity component which does not make a lot of > > sense. If it was called entity-service or entity-service-map or > > something like might have been more direct and self explanatory. > > > > I think Jacopo's comment of moving away from components to jars as the > > building blocks (at least for the framework) is a fantastic idea. It > > might involve a heavy amount of work but is definitely doable if we > > get focused. Meanwhile, back to the subject of ext components, perhaps > > many of them need to be merged and or replaced. That might include: > > - securityext: not sure why it exists > > - commonext: that's a difficult one, lots of entanglements, but none > > the less I'm not sure why does it exist and why does it depend on > > other "application" components. > > - exampleext: no idea why, but probably least useful. > > > > So following Pierre's suggestion perhaps we should generalize this > > thread and consider removing all three? > > > > On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato > > <jacopo.cappell...@hotwaxsystems.com> wrote: > >> Scott is making a good point about entity-ext: in my opinion the design is > >> good (but can be improved). > >> I suspect that commonext and exampleext have a less clean implementation > >> and maybe they do not even implement that pattern, I see less value in > >> them. > >> > >> One comment on entity-ext: In my opinion we should (for this and for > >> several other parts of the framework) continue the work to make the > >> framework code more modular (with core independent modules and with > >> extended modules that depend on them etc...) but I don't think that the > >> building block should be the "OFBiz component" as it is now. It would be > >> better to rely on jar files instead. > >> For example: > >> entity-core-api.jar > >> entity-core-impl.jar > >> service-core-api.jar > >> service-core-impl.jar > >> > >> service-entity.jar that provides the integration of services with the > >> entity engine and depends on entity-core-api.jar and service-core-api.jar > >> > >> We could define several granular modules that would allow to deploy > >> different flavors of the framework, e.g.: > >> 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to > >> legacy applications (built from scratch) > >> 2) service-core-api.jar + service-core-impl.jar: service engine available > >> to legacy applications (built from scratch) > >> 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity engine > >> available to legacy applications (built from scratch) > >> etc... > >> > >> Jacopo > >> > >> On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <scott.g...@hotwaxsystems.com> > >> wrote: > >> > >>> I'm not familiar with commonext or exampleext, but the purpose of the > >>> entity-ext component was to allow the entity engine to exist without the > >>> service engine. That's why all the entity-related logic that relies on > >>> the > >>> service engine is implemented there (EECAs, EntitySync, DCC). The > >>> alternative would be to have that stuff in the service engine, it can't > >>> exist in the entity engine because you'd have a circular compile-time > >>> dependency. > >>> > >>> It effectively exists as a "disentanglement" of the entity and service > >>> engines. > >>> > >>> Regards > >>> Scott > >>> > >>> > >>> On 8 January 2018 at 09:18, Taher Alkhateeb <slidingfilame...@gmail.com> > >>> wrote: > >>> > >>>> I think all -ext components (entityext, commonext, exampleext) are > >>>> redundant and do not add value. Any patches to fix this issue and > >>>> merge these components would be great. > >>>> > >>>> > >>>> > >>>> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <pierresm...@apache.org> > >>>> wrote: > >>>>> Hi all, > >>>>> > >>>>> The ExampleExt components provides functionality to extend widgets > >>> across > >>>>> components. In this solution, the ExampleExt component has form widgets > >>>>> extending similar widgets in the Example component. > >>>>> > >>>>> This kind of functionality (both within one component and across, and > >>>> with > >>>>> more variants) already/also exists in other components in the > >>>>> ofbiz-framework code base. > >>>>> > >>>>> So, do we still want to entertain/maintain a component that adds little > >>>> to > >>>>> no unique value for our (potential) adopters, even though it is in the > >>>>> ofbiz-plugin code base? > >>>>> > >>>>> For what it is worth: the ExampleExt widgets can easily be integrated > >>> in > >>>>> the Example component, and the existence of extended/extending widgets > >>> in > >>>>> the ofbiz-framework code base also serves as examples of what can be > >>>>> achieved by adopters/contributors. > >>>>> > >>>>> What are your thoughts? > >>>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Pierre Smits > >>>>> > >>>>> V.P. Apache Trafodion > >>>>> PMC Member Apache Directory > >
