A few questions regarding modules

English forums
1

Hello,

I have a few questions regarding the OXID module system. Obviously, because I’m posting here. :wink:

Down to business, I have been tasked to develop a few modules for OXID to integrate with our backend system. Those modules will communicate through a REST API with our backend. The modules will consist of:

  • user module (registrations, logins, profile/address(es),…)
  • article module (article data import/export, storage quantity updates,…)
  • cart module (CRUD over REST API basically)
  • delivery module (payment/shipping options for an order,…)
  • payment module (payment authorization and confirmation,…)

Plus possibly a few more, but those would be the start. Now my questions:

  • is it possible to handle all user operations through modules, so the users would effectively register and login through the REST API? I don’t want duplicated user data on OXID and our backend system.
  • is it possible to override from where OXID loads the article data(DB) and rather load it from the REST API?
  • this one should probably work, as I still want to keep the cart in the users session, for quicker operations, but non-the-less, is it possible to integrate REST API calls for Cart CRUD?
  • is it possible to load payment/shipping options from a REST API instead of the DB?
  • I would much rather not keep any order data in OXID, but send everything over to the REST API, is it possible?

I really don’t want to duplicate data between two systems, because this can lead to hellish situations as it has in the past already. But the company wants a few modules that OXID users can simply install and connect with our backend(after making a contract with us of course).

And lastly, where can I find some nice documentation for writing modules on OXID?

Thank you in advance, and kind regards,
Thomas

2
  • yes
  • it is possible, although you cant achieve that with modules and it will take big amount of time to get that working, because OXID uses a lot of hard coded sql queries.
  • yes
  • yes
  • yes

but… in conclusion you want to cut off all ecommerce functions from oxid and let the frontend communicate with your own backend. Why?
Why dont you develop a fancy (nodejs?) frontend for your backend instead of misusing an ecommerce software? i don’t think you and your boss will be happy with getting oxid work that way.

3

Well, I kinda don’t want to change core files. Don’t want to put myself into a situation where I need to do more work when upgrading.

And we already have a ecommerce frontend for our backend, although not written in nodejs, as part of a different project, but it could quickly be cloned into a standalone probject, if need be. No idea why we don’t go that way for this client. Will definitely keep that in mind for the next meeting.

Thank you!