Open dkarlovi opened 3 years ago
So it is the reverse.... where is the difference than?
Integration is done in the package which extends the featureset, not the root one providing the hooks, otherwise all the code should be in the root package and hooks are not needed at all (since package extends itself).
It's like how Data Definitions tself extends ProcessManager: the root features are in ProcessManager and Data Defs extends it.
In general,
I strongly support this issue/feature request.
Currently i have "Coreshop" in the system, but i don´t want to use CoreShop. Also in the Class Definitions are a lot of "CoreShop" Editables, which don´t work and not needed.
CoreShop should be an option if somenone uses both, not mandtory if i don´t have a shop or want to use Ecommerce Framework instead.
Currently facing issues with JS-Errors triggerd from Coreshop (in the Document Edit Section !!). That´s strange, because there should no Coreshop Stuff involved at this section/area.
So please, separate this to keep the DataDefinitions as clean as possible.
@ITspirit you don't get what is meant here. You also don't see the full picture. DataDefinitions relies on fundamental base bundles of CoreShop. These bundles make DX and live easier for me as a maintainer. Therefore DataDefinitions relies on ResourceBundle and PimcoreBundle. PimcoreBundle is the base bundle for all of my Bundles and it comes with a lot of DX features and useful extensions for Pimcore.
I will not remove that cause it troubles you. I have to maintain a lot of stuff and therefore tend to make live as easiest as possible, if that requires me to rely on MY OWN PACKAGES, I will. And CoreShop is not just about eCommerce, it is a set of bundles that can be used exactly as they are here.
If you don't like it, you don't have to use it.
Currently, the Coreshop interpreters are here, but only valid if you have Coreshop installed. They should be optionally registered from Coreshop if that bundle finds DataDefinitions is there.