# High level direction for database module development

**URL:** <https://forum.inductiveautomation.com/t/high-level-direction-for-database-module-development/66558>\
**Category:** Module Development\
**Created:** [November 15, 2022, 11:31pm UTC](https://forum.inductiveautomation.com/t/high-level-direction-for-database-module-development/66558 "2022-11-15T23:31:09Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [November 17, 2022, 4:37am UTC](https://forum.inductiveautomation.com/t/high-level-direction-for-database-module-development/66558/12 "2022-11-17T04:37:44Z")

</div>

Ignition's wicket forms are all built around the internal DB's PersistentRecord, which is totally unsuited to any other database backend. I hacked them up for my Ethernet/IP module, but figured out the non-hackish for my Modbus module. It required defining some form components that actually follow Wicket's IModel expectations for POJOs. See this post:

> [@Can I use a dynamically populated ComboBox for Gateway Web Field](https://forum.inductiveautomation.com/t/can-i-use-a-dynamically-populated-combobox-for-gateway-web-field/64073/5):
>
> Nah. Wicket works just fine. It’s just that everything IA does with it uses the PersistentRecord models. I implemented my own. The abstract base: public abstract class AbstractModelEditor\<T\> extends Panel { private static final long serialVersionUID = 1L; protected final WebMarkupContainer body; protected final FormComponent\<T\> editor; /\*\* \* Mimic's Ignition's Field style in the RecordEditForm, but not dependent on \* any PersistentRecord instance. Instead, the appropriate wicket …

---

_[View the full topic](https://forum.inductiveautomation.com/t/high-level-direction-for-database-module-development/66558)._
