I wanted to develop a module which could allow client to enter data once and then deploy it in many possible places. So I developed two modules, one for management, and the other for display. The "edit" mode for the display module is just a drop-down list where the correct vendor is selected (this is a permanent craft fair of sorts with many vendors). Then that vendor's directory info - which was entered via the management module - is displayed.

A third module is an index list of all vendors, a description, and a link to their vendor page on the site. This data, like that in the other display module, is all entered and managed in the management module. Vendors are automatically included in the index module when 'DisplayInIndex' is set to 'Yes' in the management module. They only get published when their page is good to go. There is no editing at all for the index list. Just drop it on a page.

Thus I depart a bit from the norm for DNN. I cannot store the ModuleID in the main KWCR_Vendors table since the data itself is enterprise-wide and in a sense module agnostic - it can be pulled into any module. So I have an extra table which has only ModuleID and VendorID to join the vendor data to the module. I have to make an extra round-trip to the database, sending it the ModuleID and retrieving the VendorID before I can invoke the CRVendor class and pull this vendor data into the module. Not that that's a problem, really - just that it isn't the norm and it does not match any examples I've seen.

This all works perfectly. However, I recently learned how to leverage the URLControl which I use for selecting the Vendor Page on the site in the management module. When so doing I started thinking that in some ways, though I had accomplished my goals well enough, that I had also made it less likely for me to be able to benefit from some of the ways that DNN is module-aware.

Re-thinking, I could have been more conventional and had a module which was both data-entry in edit mode as well as display, and then found other ways to re-display that data. Similarly, I could have had a query which looked at all modules were of that type and still have constructed a list of vendorname, description and link to their page for the index module. Just would have been joining on the Module definition id etc.

If any of the above is clear I am just wondering if those of you more experienced in DNN module-building would say about what I have gained by this departure from convention versus what I have lost by it.

Essentially, I am satisfied with the set of modules in that they work as expected. However, I am not so certain of the wisdom of this approach. It may leave me unable to leverage some of DNN's services, or something. This is the second time I've done something similiar - both times because I wanted enterprise-wide display made easy, and this did it - but if I am teaching myself bad habits this is the time to find out.

Very interested to hear from you more familiar with DNN module development, and thanks -