I'm not against strictly against removing exampleext (maybe merging some part in example ). But then what it not clearly tries to explain (misc.
extension mechanisms) should be clearly documented!
For commonext I need to look at it again but at 1st glance it seems redundant indeed and could be merged with common now that we deliver applications
with framework.
There is also securityext, I did not say we need to merge it, just noticing.
Anyway before doing anything we need to clarify, if possible, why those components were created and what impact it could have (if merged with there
main component) when/if-one-day we split applications and framework.
And if we merge these stuff these pages must get out also:
https://cwiki.apache.org/confluence/display/OFBENDUSER/Extending+the+common+component
https://cwiki.apache.org/confluence/display/OFBENDUSER/Extending+the+security+component
Jacques
Le 07/01/2018 à 21:55, Scott Gray a écrit :
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
