That makes sense, thanks Scott
Jacques
Le 08/01/2018 à 19:51, Scott Gray a écrit :
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" <[email protected]> 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
<[email protected]> 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 <[email protected]
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 <[email protected]
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 <[email protected]>
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
