Hi,

We have just rolled our my first DNN Portal and are working on our second for release in the next couple of months.

During that process i have read a lot about DNN, and purchased a couple of modules.

As we are I.T developers - we like process :-)

I have found that unfortunately the different modules tend to interact with the database differently, thus when i create a module to interact with both of the third party modules data, it is inconsistent. (Naming Conventions, Data Types, Locations etc)

For example the calendar module we purchased, cannot reference the new user details which were created by another purchased module....It can only reference the "core" user details. Now I could purchase the calendar source code, and update the module to draw fields for the new tables, but that would be making things worse. I should purchase the source code from the user details module and centralise its data repositry......Then update the calendar to reference that as well i suppose....

To extend the user details, I really need to know what would be the best place to store additional data, so other modules could accces it as well, hence my interest in best practice. 

Perhpas the User Details module is operating correctly and the issue resides in the calendar module. If so a request could be put to the calendar developer to update their code in line with best practices.... see where i am going...

I see from reviewing this forum, there are a few people requesting guidence about Best Practice on specific issues, and i suspect more would appear if there was a forum dedicated to it.

To start things off, one of my developers has come to me and asked, when programatically removing a user from a role, is it best to delete the entry or set the role membership to minus 1.  My reply was to do it manually, monitor the result, and then mimic that. Most of the time that would be fine, though when monitoring we may miss something...

It would be best if developers associated with the creation of pieces of core logic, could comment on the best practices put forward by other developers, that way module extensions coud be more consistent and lead to tighter intergration.

I think this product has a great future, and would like to see it reach its potential.

regards

TheTimp

you are not wrong. In our defense: it has been a busy few days, with DNN europe meetings and OpenForce europe, with a lot of active community members participating in those events.. forum responses might have been bit slacking due to this.

Also.. like you say, we are all developers.. we like process, but we dont like documentation. There is a documentation team in place right now, and they are starting to work out what their responsibilities will be. If you are interested in volunteering such documentation team, drop me a mail at erik.vanballegoij@dotnetnuke.com, and we can discuss that a bit more offline.

With respect to your developer's question about programmatically removing users from roles: that should be done by using the api methods. In order to find out how they work, just look at the source of the core module that does the same and see what functions are called

Best practice number one: never hack the database by talking to it directly: you should always use the core api to do that....

DNN Blog | Twitter: @erikvb | LinkedIn:

<<< just look at the source of the core module that does the same and see what functions are called>>>

Hi Erik,

Thank you, DNN is a great Web apps framework but let me tell you that I have heard the asnwer like that above here many times - you know if you're working with DNN for several years then, I guess, you already "learned by heart" 95% of "tricks"(DNN API calls) needed in everyday custom modules development practice, and to find another 5% of such "tricks" would be a "quick look at the DNN sources" for you, but if you're starting with DNN then that process of "just looking at the source of the core modules" is very time consuming...

Just  wondering why folks who do know how to code the most commong DNN API calls are so rarey posting them here in response on this forum participants requests?

Hope that documentation team you mentioned will also get developed freely available "DNN API Cookbook" that will be recommended reading #1 for evreybody starting DNN custom modules development...

One of the entries for this cookbook could be: "Navigation between multiple view controls within a module" - I'm currently trying to figure out from DNN sources how to do that but I still can't make it working...

Thank you.

--Shamil