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 ExtensionsModulesModulesOnly one module/extension per folder is stupidOnly one module/extension per folder is stupid
Previous
 
Next
New Post
3/14/2012 4:46 PM
 

I just read this, your last post. (it showed up after I had started my last post)  The only people who can answer why the module packager works the way it does is the good people at DNN corp.  It sounds like it would be a fairly easy fix for them but probably not a high priority.  They will probably tell you to grab the source, fix it and then submit it to the issue tracker along with the fix.  That way it will make it into the next release or so. (a pretty standard response from them)

 What does your "Module loading module" do? Is it for installing new modules?

Robert

 

Well, there are several reasons for our custom "module loading module", which basically will inject user controls dynamically into the page in more of a "plugin fashion" (just drop the modules into the "modules" folder and they will show up in the web interface without having to make any changes to the DNN configuration). Another reason is to be able to implement user access rights in the Business Layer rather than in the Web layer which is quite useful if the web isn't the only user interface (yes, I know DNN isn't only web layer but still, its....hmm....web-heavy) 

 
New Post
3/14/2012 4:52 PM
 

 Overall I think you are correct, and in most cases, the manifest solution would probably be the preferred one. Thank you for sharing this. In our case, as this is a custom made enterprise application, we don't want to put to much effort into "distribution packaging" as we don't really have any distribution, besides moving the controls from development servers to test servers and then to production servers. But this is all in house and DNN is only a part of a much larger solution. 

That said, I still believe the proper solution here would be that future versions of DNN was improved with regards to this. Haven't looked into the problem more in detail, but I guess is that all it would take is to allow the user to specify a package name instead of just taking the name of the folder containing the user controls, and the problem would be solved, right? 

 I totally understand the part about not wanting to put to much effort into distribution packaging.  Pretty much all of my DNN development also falls into the "enterprise app", "for internal use only" scenarios.  But I have found that the initial rollout to the dev servers and then the prod servers went pretty smoothly by using an install package and that the effort in creating the manifest file was really minimal when compared to the overall project.  And then updates to the modules are just a matter of publishing files.  We don't worry about creating new install packages.  Just publish the controls, images, dll's etc.. directly. 

Anyways,  good luck with your project.

Robert

 
New Post
3/14/2012 5:48 PM
 

 I totally understand the part about not wanting to put to much effort into distribution packaging.  Pretty much all of my DNN development also falls into the "enterprise app", "for internal use only" scenarios.  But I have found that the initial rollout to the dev servers and then the prod servers went pretty smoothly by using an install package and that the effort in creating the manifest file was really minimal when compared to the overall project.  And then updates to the modules are just a matter of publishing files.  We don't worry about creating new install packages.  Just publish the controls, images, dll's etc.. directly. 

Anyways,  good luck with your project.

Robert

 You are probably right and I guess if we hadn't had our own "module loading module" solution that would probably have been the best approach. As it is now, the number of DNN modules are actually quite small, only the loading modules basically, which then includes 35+ modules that implements the actual application logic. 

 
New Post
3/15/2012 9:46 AM
 

I think that there are a number of people who also take your approach of dynamically loading controls.  (say one base module that just acts as a place holder for the dynamically loaded control / controls)  It does make the setup in DNN a bit easier.  

Robert

 
Previous
 
Next
HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesOnly one module/extension per folder is stupidOnly one module/extension per folder is stupid


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