Forum


HomeHomePremiumPremiumDevelopmentDevelopmentMultiple Package Module File Naming ConventionMultiple Package Module File Naming Convention
Previous
 
Next
New Post
9/26/2013 1:49 PM
 

Background:  I am creating a suite of modules that will all share code.  Scott describes how to setup the DNN manifest file to support this in another thread.  Initial testing went well and allowed me to install multiple modules using one install package. 

The question I am faced with now is how to name and organize my files as the project grows.  Every module it seems will need the Edit, Settings, and View file.  In the sample template from Christoc these files are named Edit.ascx, Settings.ascx, and View.ascx and are placed at the root level of the project.  This works great for a single module, but when it's time to add the second module to the package it is decision time.

Are there any established naming conventions in the DNN community for this?

For example, lets say I have these modules to create: MyShoppingCart, MyCheckout, MyProductPage.

My initial thought was to create a folder for each module, named with the name of the module in the root of the project and keep the files named Edit.ascx, View.ascx, and Settings.ascx.  Another thought was to create files for each by putting the module name in front and leave them all at the root, MyShoppingCartEdit.ascx, MyShoppingCartView.ascx, and MyShoppingCartSettings.ascx.  The problem I see with either of these approaches is that over time if many modules are added, the project is going to look kind of ugly with all these files/folders at the root.

After considering the above, I am thinking that a good way to approach this is to create a folder at the root called "Views" and place folders inside for each module named with the module name.  Inside each of the module folders there will exist the Edit.ascx, View.ascx, and Settings.ascx files for the module.  This should allow the project to scale while keeping the root view project of the project clean and manageable. 

This seems like a reasonable option but before I commit to it I wanted to check around and see if there are already established conventions that I should consider using.  If anyone has any advice, please let me know.

 
New Post
9/26/2013 8:06 PM
 

Andy,

I work for Bluebolt, a sister company of PackFlash.  I was looking to see how they do there packaging since their suite of modules are all packaged together.  You can download a FREE TRIAL and see how they do it.  They take more of the first option you mentioned: creating a folder in the root module folder for each module definition to put the module controls.  This makes sense for them because their modules need their own resources (javascript, images, etc) which they put in the folders to keep them organized.  I have done simpler module packages where my module definitions shared resources and I just named the views differently and put them all in the same folder.  There is no convention as far as I know, just do what's right to keep your project organized.  

 
New Post
12/9/2013 9:49 AM
 

Recently I have discovered several bits of info I thought would be helpful for this post.

I have multiple modules in a single project and the way of dividing up the files as described in my first post seems to be working well except it is incomplete.

As I got working with the project I noticed that the Resources file and CSS wasn't functioning as expected.  To get access to the resource files and CSS I needed to move the App_LocalResources folder into the folder containing the views for the module.  I also had to do this with the module.CSS file.  It seems that these two items must be placed at the same level as the .ASCX files for the module.  Here is the folder structure I currently work with:

MyProject

-->Views (folder)

---->MyModule (folder)

------>View.ascx (file)

------>State2.ascx (file)

------>module.css (file)

------>App_LocalResources (folder)

-------->View.ascx.resx (file)

 
Previous
 
Next
HomeHomePremiumPremiumDevelopmentDevelopmentMultiple Package Module File Naming ConventionMultiple Package Module File Naming Convention



Try FREE
30 days money back guaranteed