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

HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesAdvice needed on tempting projectAdvice needed on tempting project
Previous
 
Next
New Post
4/5/2014 10:29 AM
 

If I can every get my module coding back on track I wish to finish upgrading my codesmith template suite. I started this in the dnn 4/5 days and got it to the point where about 85% of a vb module would generate and maybe 50% of a c#. The idea was a fully operational module out of the gate, with a dal and ui that was set up to match your tables. By tables I mean plural, and I'm testing with one database with 50 tables, another with 20. I also created code for DNN functionality like import, export, and search. I also include embedded comments, copyright headers, and generate the RESX based on the descriptive metadata in the database. I wish to generate commercial quality code, not a QAD example.

I'm part of the way through upgrading them to dnn7 as I intended to use this as my means to upgrade my modules. For now I'll fix the dal bits and go back to dal2 later, but I'd like to add knockout generation, giving the option of dal/dal2 and web forms vs knockout. The idea being a working crud module out of the box that does things the "dnn way", that got all the tedious stuff out of the way so you concentrate on ui enhancement and business logic. Ideally this module would be free of custom libraries or odd build processes that would make it difficult to finish the coding without learning some "special" framework. 

I'm already using Scott Wilkinson's template as a guide, along with the Christoc templates. I'm also looking at Scott's Client Centric examples. Those are good examples, but Scott and Chris have slightly different topologies for both the file systems and name spaces. When I look at other core modules and examples people have very helpfully pointed out I see more differences. I would like to have a matrix put together that shows put your models here, and use this namespace, and your utilities here, and use that namespace, and your UI elements, etc, and import these name spaces and use those name spaces. A cookbook that takes you past the fairly simple examples that are available. When I look at more complicated modules, like Events, there's yet another topology, so without knowing WHY they are put together that way it's difficult to know which model to follow. 

Ideally I'd like to use the templates to completely refactor other modules I have to the "new" standards. Some are kinda messy, since I was learning how to so something while I did it and a redo would make cleaner and more maintainable code. Get a nice clean structure, UI, and DAL, and use that as a base to pull the rest of the code forward. I'd really like recommendations on the folder structure, namespace organization, and default functionality. 

I would also appreciate some reviews of the resulting code. For example if someone sends me some DDL I could run my templates against it and send the code back. If you already have codesmith I'd be happy to share the templates in exchange for feedback.

 
New Post
4/5/2014 1:26 PM
 

I wouldn't be too worried about project layout as often it's a personal style issue, rather than anything architectural or technical. The "style" often changes on the approach used e.g. a single-page application (SPA) will have a slightly different organisation than a "traditional" dnn usercontrol based project. In the platform today we predominantly do SPA style development so you'll see a number of examples, with DNN Platform\Modules\MemberDirectory probably being the most typical.

 If I was using knockoutjs in a new asp.net MVC application I would have separate model, view and viewmodule folders (as knockout is an MVVM implementation), but in DNN's case as the view (the user controls) are conventionally in the route of the module they're left there, and the model is basically DNN (and whatever extensions the module add's -typically in the "components" folder to match the existing DNN conventions), there's only a "ViewModel" folder. However as we're going to populate the SPA with data we retrieve via ajax requests, there's also a "Services" folder to contain them, a "Scripts" folder for the javascript, and a "Templates" folder for any reusuable knockout templates (this is handy as we can then reuse standard code to load and allow dynamic editing of templates). There's nothing too earth-shattering about this structure, it's just one that we've found made sense and is easy to understand and repeat.


Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US
 
New Post
4/5/2014 2:10 PM
 

What I need advice on is a structure that's amenable to larger applications. For example the project I'm in the process of converting has 16 tables, 4 lookup tables, a half dozen temp tables, and 6-8 views. Since they're inter-related it's impractical to split it up into multiple projects even though there'll be multiple modules to facilitate the security model and the various views of the data. The data tables will have a normal list, select, edit style CRUD operation but with some of the tables having tens of thousands of rows it's not like a normal paging form will work. Lookup tables will likely be single forms with an editable grid accessed through module actions (like in Events).

While the structure can be thought of as personal preference, there are definitely ways to things from a project and namespace standpoint that fit better with the DNN structure and namespace than others. So when I look at something like the structure generated by the common templates I wonder if that's going to be practical when there are potentially dozens of forms, models, etc. The template builds the structure, and it's a lot more trouble to try to move things around after the initial build out than to set things right in the first place. That said, something overly complicated would make it confusing to someone using the templates for something smaller.

Using the "old fashioned" way of keying stuff in after the base project is laid out by the T4 template runs out of steam when you have multiple tables, or even a lot of fields in a few tables. Even hand stepping through various model, repository, view, edit, etc, templates one at a time for each table isn't much fun either. What I do is select a list of tables, some naming conventions, and let 'er rip. Out the end of the process should come a nearly functional module.

I've used a number of code generation schemes; IronSpeed, CodeOnTime, ASP.Net Maker but the issue always comes down to integration with the DNN platform. All have a basic framework they use that doesn't always pay nice with DNN, so then you're looking at issues if you want to act like a regular module and do search, importable, etc. That's why I'm back at my CodeSmith templates, since I can create code just like hand-coded DNN with nothing in the way.

 

 
Previous
 
Next
HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesAdvice needed on tempting projectAdvice needed on tempting project


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