Possible to generate tables with the bundle?

[Int-Circuit]

Hi, I need some help regarding this bundle.
I need to generate a table in my settings but i cannot seem to find a method allowing me to do it.
Is there something in the bundle allowing me to create such a table or do i need to use something else from Symfony?

thx a lot in advance

[jbtronics]

What kind of table do you mean?

A database table? A form table?

[Int-Circuit]

I'm currently working on the interface for the serial port feature for PartDB, which can utilize usb serial or gpio. For the latter, i need to implement a pin selector.
Since all sbc manufacturers use a slightly different pin association with each of their boards, I had the idea of creating a 420 table with the 220 containing checkboxes for each pins and the outer ones having pin names (recovered from a yaml file), ie having something like that

[Int-Circuit]

@jbtronics ping since idk if u had the reply notification

[Int-Circuit]

Hi @jbtronics, just a little ping regarding the question above.
Thanks

[jbtronics]

You can implement custom parameter types to store arbitary data. For simple bool ArrayType might be enoug. And there is also SerializeType for unstructured arrays. In all cases you will need to implement a custom form type, but that is done and documented by symfony/form, not by this bundle.

That being said, i am not sure if it is wise to configure that details in Part-DB. I think Part-DB should save some URL or something, via which it can connect with another software handling the hardware interface stuff. and then configuration of details like this should be handled in that software. Not in Part-DB.
Also not sure why the pinout plays a role at all, shouldnt that be handled by the OS, and software just access an tty dev file? Then it should be enough to just give the path to the tty interface that should be used.

[Int-Circuit]

Hi @jbtronics, thanks for the answer. Regarding the pinout i thought about adding either serial or simple I/O access to Part-DB. However after ample reflection the last part would better be suited to a MCU connected in serial to the hardware running the server, which would dictate how to handle the I/O data.

As for the config for serial, you are right, settings in PartDB should be kept to a minimum (toggle serial comm. and specify serial port). Rest would be handled by the middleware program and communicated to him trough API/webhooks.

PS: Apropos API, I sent you an email to ask if you could tell me where the API is constructed (which files have it's definition) + some example of working POST Requests. Could you please send me those informations? It would help a lot.

Thanks again for your work and taking time to respond