Certainly an ambitious but interesting idea
Le 08/01/2018 à 11:29, Jacopo Cappellato a écrit :
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
