ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Gray <scott.g...@hotwaxsystems.com>
Subject Re: [DISCUSSION] Disentanglement of the ExampleExt component
Date Mon, 08 Jan 2018 18:51:35 GMT
My memory is vague on security-ext but I think the purpose was to extend
the security component for application-level functionality (as opposed to
framework-level). For example the UserLogin.partyId field was added to the
schema in this component because the framework wasn't supposed to have any
concept of the Party model.

Regards
Scott

On 9/01/2018 7:14 AM, "Taher Alkhateeb" <slidingfilaments@gmail.com> wrote:

> 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.cappellato@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.gray@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 <slidingfilaments@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 <pierresmits@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
> >> >
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message