Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Implementing IPortable - best practices for complex moduleImplementing IPortable - best practices for complex module
Previous
 
Next
New Post
4/16/2007 9:33 PM
 

One of my last tasks in developing a complex module (14 controls, 9 tables, 84 sprocs) has been to implement IPortable. Although I've done the basics of this for several other simpler modules (usually using the XmlLSerialization classes), I'm wondering how best (and how much time to put into) handling the following data structures:

1. There are two main tables  - basically setting up a 1 to many relationship between "requests" and "updates" linked via a RequestID column.
2. Both the Requests table and the Updates table have several columns setting up foreign key relationships with the DNN Users table, a Moderators table (linked via UserID) and 5 different "category" like tables (linked via various ID columns). The "category" tables can be edited and added to by Administrators so do not contain static data.
3. Many ModuleSettings are used - primarily for enabling various module options but also for some module wide statistics storage.
4. Two custom permissions are created - Moderate and Post

Questions:

1. Serialiazation of all of the various data structures (including all the various "category" tables) for ExportModule is tedious but easy. The tough design decisions come in implementing ImportModule:

A. Rebuilding the one to many relationship between "requests" and "updates" can be handled easily as each is added to the database

B. Rebuilding the relationships between the various "categoryID" fields and the restored "category" tables is harder. I'm handling this by first adding the deserialized "category" information  to each table, building a key-value dictionary between the text of the "category" and its new ID then as each "request" and "update" is added replacing the exported "category" text with its new ID. Not the most efficient, but I can't think of any other way to do it.

C. My main problem comes with the use of the UserID for tracking authors, editors, moderators and for subscribing to new request/update notifications.  Should I try to preserve this information knowing that a only a few or even none of the UserID's might be valid for the portal into which the module content would be imported? Should I export Usernames rather than UserID's and try to match these to users in the destination portal? Or, should I forget about trying to maintain any of the UserID based data? Even if I were able to match by Username and populate the UserID based fields with their corresponding values, there is still the problem of the matched users not having the proper security roles for the two custom permissions.

D. Does one try to export/import appropriate ModuleSettings - particularly when they relate to enabling such features as allowing one to delete/edit their own requests and updates, moderation vs. unmoderated posting, etc.

I'm tempted to skip the whole implementation of IPortable as I don't really need it for my current use case, but feel that it should be included as the module will be offered commercially at a later date.  Now I know why the current DNN Forum module does not implement IPortable!!


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
4/17/2007 12:20 AM
 

Ouch - cant help but get the feeling that you are over thinking this one.

IPortable is a pretty cool feature of modules - but by the same token - seems best designed for simple modules or one activity modules where the data that is exported and imported makes sense.

In your case = handling module settings and categories would make the module portable in the general sense - that is you could export the module and reimport it and it would functionally work the same.

Once you get beyond this - that is trying to re-sync the entire data contents of the module collection to a working dnn portal - it really starts to get into the catefory of - would anyone ever really do it - and for what reason.

About the only reason - without fully understanding how your module works for doing a full export could be for backup and transfer purposes -

As such - If you are simply trying for example to recreate the categories on a new site - and assuming that you are starting with a clean set of tables - then there is really no need to fiddle around with things like key-value dictionarys - it would be simpler to temporarily turn off the idenity / unity of the catefory id for example and simply use the existing idkeys.

The same would surely be the case for the only real reason for actually re-importing the other user related data - that being as a backup and transfer of an entire site.

Westa

 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Implementing IPortable - best practices for complex moduleImplementing IPortable - best practices for complex module


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out