Forum

Hy there.

Thank you Scott  for the great tutorials and insights about Module Development in dnn.

i'm quite new to dnn7 and a little confused about the approch to Moduledevelopment.
 

In many cases my intention is not to package and distribute modules. Instead i want to develope modules for a specific task  requested by a

specific customer.

In such a case, must i care about module-project- templates, manifests, and dataaccesslayers dnn offers to me?

isn't it enough to simply write my functionality(ascx) , add a connectionstring to the 'main'config-file and access the database, all in common asp.net manner?

in the end building and copy the 'project' to desktopmodules-folder and derive it from a dnn modulebaseclass.

in the end i the 'module' would be even more seperate from the dnn-core so i guess less problems when dnn updates.

is this a practical and common way and where are the downsides of this approach? What would you recommend?

regards

albert

Thank you Anderson for your reply.

The question arised when i joined the project of a friend. They really use  DNN 'only' as kind of Portal, as a Wrapper which offers a lot of default functionality they don't want to code themself, like usermanagement and so on. As a small team the heavely rely on third party tools like DevExpress. On my question how to integrate for instance devexpress gridview properly in DNNenviroment they simply done the following.

They created an aspx webform (they use iframe on defaultskin) connected to their own database with a simple sqldatasource, bind it to the grid. in the code behind they derived from dnn PortalModuleBaseClass. They copied the files to desktopmoduldirectory and registered the view(aspx) through the backend of Dnn (create module).

trag in the module on contentpane...et voila.  Devgrid in DNN site.

in the end a great proof for the simpliness and possibilities of DNN. So they do not use dnn services and DAL directly.nor templates and manifests at all.

Perhaps their way is too obvious to mention . But for me it was an eyeopener. Perhaps it would be worth to clarify this approach in a basic video or writing.

Of course there is not one right way. And that's good enough.

However thank you for the great site. I've learned in the last few days more than in the weeks before searching the net for useful infos about dnnWorld .

regards

Albert

Albert,

I have seen many ways to customize DNN, using Iframes and techniques like you described. The goal of a CMS is to offer your users the ability to customize the website themselves.  Spending a little extra time to integrate your module with DNN, ie: put options into module settings, integrate with the core API for emailing, messaging, user management, security, etc are worthwhile features because it means your module will be flexible, upgradeable, and will not do unexpected things for the user.  

I understand if you are looking for shortcuts because of budget, or the site has an end-of-life and won't require DNN upgrades - then do what you need to do to fit the right solution with the project.  You just need to always think of how the solution gets maintained over its lifetime.

Once you do a few modules using the DNN API and DAL, it does get easier and faster to implement modules the correct way going forward.