Hi Guys,

In the documents module sub-project team, we've been discussing some user controls/tables that are (almost) an exact match for the UDT data structures, so I thought I'd post here and see if we can use each other's work (actually, more just us using your work!).

We're trying to build the ability for users to add user-defined fields to each document entry, and for these to be able to be displayed in the documents list (again, user-defined).  Our design was intended to allow this functionality to be rolled out into other DNN modules as well.  Our table designs are almost the same as the UserDefinedFields table (even down to the table name!), but we've got a couple of extra fields (listed below).  The really important fields are marked in blue, the others are "nice to have":

UserDefinedFields

DesktopModuleID:  Link to the DNN DesktopModules table - defines that this field is "for" that module.

FormatString:  VB-style formatting string, used to format the value for output

ValidationExpression:  Regular expression for data input validation

UserDefinedData

ItemID: Item ID (within a specific module) that the data is stored for (or zero, for modules that don't support multiple data items).  In the case of the documents module, this would be a link to Documents.ItemID.

UserID:  User ID that the data is stored for (allows for per-user data storage), or zero.

UserDefinedRows

We don't have one of these in the design, because we had ModuleID in the UserDefinedData table... but that's ok, the existing design will work for us.

What's the chances of us collaborating to get these fields added to the UserDefinedFields/UserDefinedRows tables so we can use your work (and tables) in the documents module?

Thanks Sebastian,

Have you had a chance to discuss this as yet?

Anthony,

we discussed co-operation with your team within our team and for sure this contains many interesting aspects for further developement of both modules and DNN as a whole. We see many routines and controls, where we should avoid double efforts and should rely on tested components of each others module - not to get modules with congruent functionality, but to get modules with specific benefits and be able, to concentrate on these specific features - in order to get the most benefit to DNN users. 

Please note, that we have recently started to enhance UDT module and as a result, we are currently discussing re-design of various parts of the existing approach. We try to take into account needs of other modules, that might profit from utilizing UDT. From the current developement status, I suggest using individual adoptions of our data structure and data provider.