store data in module dashboard

[froot]

OK so this might be a very dumb/basic question which is why I can’t find any docs on this topic.

I want to develop a module, namely a very basic e-commerce checkout function. For that to work, I need to store the purchases and the user input somewhere in the database. I haven’t really developed any PW module as such before, just simple pages with fields, any user input either ended up being sent via email or being stored in some field on the page. 

I guess it‘s not the best practice to create a field solely for that purpose on the page the checkout happens on, just as I‘m not putting the code on a page template either, since it‘s supposed to be a module and not just a page. The user input I would display in some sort of dashboard, somewhere on the module‘s admin page. 

So where and how and do I at all create a „fields“ for that reason or what is the right way to go about this?

Thanks for help.

[MoritzLost]

You have a couple of options:

• You can create the required fields (and templates, if any) programmatically in the install() method of your module (see the documentation). Creating fields through the API is pretty straightforward, though you might have to dig a bit to find the properties you need if you want to customize the field's settings. In this case, you should probably also handle removing those fields in the uninstall() method so your module can be uninstalled cleanly (make sure to warn the user that uninstalling the module will remove all of it's data in this case!). The benefit of creating regular fields in your module is that your module's data can be managed through ProcessWire's regular interface, and you don't have to provide your own custom interface for simple CRUD operations.
• An approach that might be better suited if your module is targeted at developers is to make the fields to be used for storing data configurable. You can build module configuration options to let the developer select which templates and fields are used to store the data your module uses. Though this doesn't work for every use case.
• Finally, you can bypass regular fields entirely and store your module's data seperately. The advantage of that is that it's easy and quick. The downside is that you will have to provide your own interface for displaying and editing your modules data. Of course, that doesn't apply to every module – for example, you wouldn't need an editor interface to edit a user's cart. But if you store completed transactions, your module users will probably expect an interface to list (export, edit, delete, ...) all transactions, at which point you would have to build your own interface for that. Where you store the data is up to you:
  • In the session or cookies (only for ephemeral data, like a cart).
  • In a page's meta() data. I do that in some of my modules, see my post here.
  • You can also use a custom database table for more elaborate storage capabilities. Again, you would use the install() and uninstall() methods of your module to create and (optionally) tear down your custom tables. See this post for some examples.

Personally, I prefer modules that adopt best practices of the system they're build for – in the case of ProcessWire, I'd say it's best practice to create regular fields and templates instead of custom tables. But the ultimate answer is – as always – "it depends".