Totally new to DNN. I have d/l and installed it, and messed around with the user interface. I'm trying to decide if DNN is appropriate for my app.

I have been developing MSSQL Server database apps for years, using a variety of front ends (MS Access, VB, ASP, ASP.NET, etc), and I generally use stored procedures to do the grunt work. I now have an old Access app (10 tables, 20 or so forms) that I want to upgrade to ASP.NET. The primary purpose of the app is data entry (CRUD) and reporting, so using Visual Studio web development would be fine. But I can see the value of using DNN to expand my app into a portal instead of just data entry, and DNN would potentially speed up user interface development/testing.

I want to use GridView/formView/DetailView/ListView, etc. in the application. Conceptually, how would this be developed in DNN? Would each old data entry page be developed as a new DNN module and added to a page? Or would I just develop ASP.NET pages as usual, and call them from DNN?

Thanks!

I can appreciate when you first look at DNN modules it can be a bit confusing as to how to start/structure your application.  The term 'module' is heavily overloaded and just confuses the matter. The term 'module' is commonly used to mean a module package.  Ie the 'forums module' is actually a package of modules that work together to make a forum.  The overloading of Module is so built-in to the community lexicon it's not going away, so you just have to acquaint yourself with what it means.  For most people it is no problem because they aren't developing a module.

Here's how it's logically laid out:

- 'Desktop Module' aka 'Module' or 'Module Package' 

--Folder[s] (one or more per Desktop Module.  These are created under the 'DesktopModules' path when you install a module package.)

----Module[s] One or more modules.  Each one of these shows up in the 'install module' drop down in the control panel

------Control[s]  One or more controls.  Each of these maps to a physical usercontrol (.ascx file) in your DesktopModules\Folder\ path.

Note that each control can either be the 'default' control for that module (<key> property omitted) or it can have a <key> value supplied.  The difference is in the Url : mypage/tabid/66/default.aspx will show the default module, mypage/tabid/66/mid/185/ctl/controlname/default.aspx - will show the control named where controlname = <key>controlname</key> in the dnn file.  You can see this in action in most of the standard modules because they have an 'Edit' control, and when you choose 'edit' you can see the ctl/edit in the Url for the edit page.

You can see this relationship if you look at the .dnn file for a module installed on your system, then look at the file structure of your site and see how the two fit together.

There's really two ways of attacking the module development problem:

1) build a module package that contains one folder, and one 'Module' within that folder.  This is how the DNN blog module is put together.  When you install the module,  DNN throws about 8 controls onto the page and you have to manually move them about to get your desired outcome.

In your case, you might build a 'Data Entry Module', which contained a couple of different controls in a single module, contained in a single folder.   You'll probably have one view and one edit control per logical page. 

2) build a module package that contains a couple of folders and a couple of modules.  This helps with implementing the module into your DNN pages, because you can logically construct things a bit easier, but clogs up the module install drop down with lots of different bits.  If this was the case, you'd have a 'GridControl' module for doing grid edits, and a 'listcontrol' for doing lists.

Which one suits best will depend on the nature of the application you're going to build.

But, to conclude, I will +1 to Tom as this has all been done before, and if you're looking at plain vanilla data-in, data-out applications, there's a couple of mature modules around to handle this.  ListX, IndooGrid and XMod spring to mind, though I've never worked with any of them - because I'm a diehard roll-your-own-module developer :)