hi,
i am followed the bundle with the purpose to see other connections to oxid than my own, that we created the last weeks. So i wanted to have a look into the migration. At the first view the mapping on the database cols seems to be very cool and easy, but it isn't oxid has got a lot of logic in their objects, that manipulates them. So you can't see the database tables as the entities you can work with. I will give you two examples:
Price calculation
You won't ever see the value of OXPRICE in the frontend. The value is manipulated depending on several shop settings (net/brut view, payment rules)
Translated text - Title of a product
Your mapping will work for shops with one base language. Oxid generates the translations by adding an extra col to the database table like title_1, title_2, ... So you won't be able to map the right col in your entity for the migration.
I would see two different solutions. Both base on the situation, that you need Oxid the oxid logic (means the shop it self) in between.
- Create a SDK
That means the Connector would just define some interfaces and services to to update the Ongr values. So the oxid shop devs would create its own module with its own logic to connect to Ongr. They would just extend the oxArticle 's save()/delete() method and create their own mapping to the document you persist. Mostly the devs would same methods/mechanism that oxid is calling when creating the values for the frontend.
- Implementing that Connector and bootstrapping parts of the shop ...
... to call its own logic while fetching the values from the objects.
Even when i would mean to create an other package/module, i would prefere the first solution.
hi,
i am followed the bundle with the purpose to see other connections to oxid than my own, that we created the last weeks. So i wanted to have a look into the migration. At the first view the mapping on the database cols seems to be very cool and easy, but it isn't oxid has got a lot of logic in their objects, that manipulates them. So you can't see the database tables as the entities you can work with. I will give you two examples:
Price calculation
You won't ever see the value of
OXPRICEin the frontend. The value is manipulated depending on several shop settings (net/brut view, payment rules)Translated text - Title of a product
Your mapping will work for shops with one base language. Oxid generates the translations by adding an extra col to the database table like
title_1,title_2, ... So you won't be able to map the right col in your entity for the migration.I would see two different solutions. Both base on the situation, that you need Oxid the oxid logic (means the shop it self) in between.
That means the Connector would just define some interfaces and services to to update the Ongr values. So the oxid shop devs would create its own module with its own logic to connect to Ongr. They would just extend the
oxArticle'ssave()/delete()method and create their own mapping to the document you persist. Mostly the devs would same methods/mechanism that oxid is calling when creating the values for the frontend.... to call its own logic while fetching the values from the objects.
Even when i would mean to create an other package/module, i would prefere the first solution.