Yes also, it's all about documenting IMO, either inside the component (my preference, either merged with example - not my preference again no not mix
things, outside only (not my preference, blur things, using inside doc outside is OK IMO) or even w/o (which even less my preference)
We have a saying in French: "Whoever wants to drown his dog accuses him of rage". Here the dog is the exampleext component, not sure why we want to
drown it, apart that it lacks documentation.
Jacques
Le 09/01/2018 à 15:37, James Yong a écrit :
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
