Developer forum

Forum » Development » custom asp.net pages

custom asp.net pages


Reply

I would like to know best practice for adding custom asp.net pages/application to an existing DW solution.


 


1) Where should the pages/applications, web.config, bin folder be placed (virtual dir) to avoid clashes with exisitng code?


2) Any specifics about web.config?


3) How much (if not everything) of the pages/applications should be uploaded?


4) Is is possible (for us) to create new virtual dirs for custom stuff or do we have to request this? 


Replies

 
Reply
Hi,

The best way to extend DW's functionality is through making a custom module. Try to download this sample solution (http://developer.dynamicweb.dk/Admin/Public/Download.aspx?File=Files%2fFiler%2fDeveloper%2fDownloadfiles%2fSoftware%2fCustomModulesVB.zip) and see how it works.

Anyway, if you still want to make your own asp.net pages, you are able to do it as you do in any other project, since this is an ordinary ASP.NET solution.

Feel you free to ask me any details about the custom modules development.

Vitaly.


 
Reply
vme wrote:

Hi,



The best way to extend DW's functionality is through making a custom module. Try to download this sample solution (http://developer.dynamicweb.dk/Admin/Public/Download.aspx?File=Files%2fFiler%2fDeveloper%2fDownloadfiles%2fSoftware%2fCustomModulesVB.zip) and see how it works.



Anyway, if you still want to make your own asp.net pages, you are able to do it as you do in any other project, since this is an ordinary ASP.NET solution.



Feel you free to ask me any details about the custom modules development.



Vitaly.







I'm well aware of the deal with Custom modules and also it's limitations, like the fact everyting is in the same project making the development of modules impossible if a solution already contains custom modules. 

It's rarely the case that another house is willing to give you their source code, I know I wouldn't.


 


But about the custom pages. What I wanted to know is stuff like where you prefer output to be placed.


I would assume:


 


*.aspx files : in some folder under Application.


*.dll : in the bin folder under Application.  


 


But if other locations are preferred I'm all ears.


 


About the virtual dirs, I assume that any folder we create under Application (via say FTP) would do just fine.

 
Reply
You can place any number of custom modules in a single solution.

As for placement of your .aspx pages I can't imagine any rule except your own opinion, so, any place.

Vitaly.
 
Reply
vme wrote:



You can place any number of custom modules in a single solution.







As for placement of your .aspx pages I can't imagine any rule except your own opinion, so, any place.







Vitaly.






I know you can place n modules in a solution, but imagine this scenario: 




Customer (A) has asked a company (B) to develop some custom modules for their solution (C). 




Company (A) then askes me company (D) to also develop some modules for their solution (C). 




Will company (B) hand over their source code to me just like that, so I can add my modules to solution (C) ? 




I don't think so.




 

 
Reply
If companies B and D will use unique namespaces for their custom modules, customer A can just include dlls with their modules to customer's application and use these modules. Am I missed something?
 
Reply
vme wrote:

If companies B and D will use unique namespaces for their custom modules, customer A can just include dlls with their modules to customer's application and use these modules. Am I missed something?



Either that or I'am missing somthing...


 


My understanding is that there is one and only one CustomModules.dll per solution.


If one company has already plastered a solution (an online solution) over with custom modules (wrapped inside CostumModules.dll) adding additional modules would not be possible unless:


 


- I send my source code to the initial module developers plus the required changes to default.aspx and ask that they add it to the solution, build it and upload it.


 


- Or I wrap my modules in DLLs, send my DLLs plus required changes to default.aspx to the initial module developers and ask that they add it to the solution, build it and upload it.


 


- Or they send me their source code and I add my stuff, build it and upload it.


 


Either way DLLs or not, the solution needs to be re-build by somone and that somone needs the other part's modules (DLLs, source, whatever) so the new build contains all previous modules plus the new ones.


 


Or am I not getting how this scenario is supposed to be handled?

 
Nicolai Høeg Pedersen
Reply
pl@xtendit.dk wrote:

vme wrote:



If companies B and D will use unique namespaces for their custom modules, customer A can just include dlls with their modules to customer's application and use these modules. Am I missed something?






Either that or I'am missing somthing...




 




My understanding is that there is one and only one CustomModules.dll per solution.




If one company has already plastered a solution (an online solution) over with custom modules (wrapped inside CostumModules.dll) adding additional modules would not be possible unless:




 




- I send my source code to the initial module developers plus the required changes to default.aspx and ask that they add it to the solution, build it and upload it.




 




- Or I wrap my modules in DLLs, send my DLLs plus required changes to default.aspx to the initial module developers and ask that they add it to the solution, build it and upload it.




 




- Or they send me their source code and I add my stuff, build it and upload it.




 




Either way DLLs or not, the solution needs to be re-build by somone and that somone needs the other part's modules (DLLs, source, whatever) so the new build contains all previous modules plus the new ones.




 




Or am I not getting how this scenario is supposed to be handled?



Hi Peter


 


You are right. The name of the dll is just the default name so you can allways rename it and it will still work. So if you have 2 solutions with modules you would under all surcumstances have to rename one of them to use them in same solution.


 


You can then add both dlls to the /Bin folder and the .aspx files where they should be, but you will have the issue with calling the modules from default.aspx.vb/cs - they would have to be added to the case statement in CustomModuleHandler.


 


With the january release of Dynamicweb we will introduce a couple of new things on custom modules development that, among other things, adresses this issue.


 


Instead of calling the modules using the case thing, you will be able to have your render class inherit a base class and tag the class. Then Dynamicweb will load and call it automatically so you dont need to specify the module in the case statement.


 


With this feature it will be possible to get an assembly and some .aspx files and just copy them to the solution - providing the namespace issues as Vitaly mentions are not a problem.


 


More on this in start of january and on the partnerkonference in Odense on 22nd of january.

 
Reply
NP wrote:

pl@xtendit.dk wrote:



vme wrote:







If companies B and D will use unique namespaces for their custom modules, customer A can just include dlls with their modules to customer's application and use these modules. Am I missed something?












Either that or I'am missing somthing...








 








My understanding is that there is one and only one CustomModules.dll per solution.








If one company has already plastered a solution (an online solution) over with custom modules (wrapped inside CostumModules.dll) adding additional modules would not be possible unless:








 








- I send my source code to the initial module developers plus the required changes to default.aspx and ask that they add it to the solution, build it and upload it.








 








- Or I wrap my modules in DLLs, send my DLLs plus required changes to default.aspx to the initial module developers and ask that they add it to the solution, build it and upload it.








 








- Or they send me their source code and I add my stuff, build it and upload it.








 








Either way DLLs or not, the solution needs to be re-build by somone and that somone needs the other part's modules (DLLs, source, whatever) so the new build contains all previous modules plus the new ones.








 








Or am I not getting how this scenario is supposed to be handled?






Hi Peter




 




You are right. The name of the dll is just the default name so you can allways rename it and it will still work. So if you have 2 solutions with modules you would under all surcumstances have to rename one of them to use them in same solution.




 




You can then add both dlls to the /Bin folder and the .aspx files where they should be, but you will have the issue with calling the modules from default.aspx.vb/cs - they would have to be added to the case statement in CustomModuleHandler.




 




With the january release of Dynamicweb we will introduce a couple of new things on custom modules development that, among other things, adresses this issue.




 




Instead of calling the modules using the case thing, you will be able to have your render class inherit a base class and tag the class. Then Dynamicweb will load and call it automatically so you dont need to specify the module in the case statement.




 




With this feature it will be possible to get an assembly and some .aspx files and just copy them to the solution - providing the namespace issues as Vitaly mentions are not a problem.




 




More on this in start of january and on the partnerkonference in Odense on 22nd of january.






Really looking forward to seeing this issue with costum module solutions with 2+ actors addressed... has been a show stopper on several ocations.
 
Reply

I've addressed the issue about having different sets of custommodules in one solution by making af custom ParagraphProvider following the ASP.NET Provider Model specifications.


 


Our situation is somehow different because we have many modules that we sell and some customers have custommodules already and just wants an extra one, so instead of adding a souce-code-copy into the custommodule solution and recompile and upload, we are able to have multiple dll-files containing each module completely isolated from others.


 


The main idea is to load different dlls and call different modules inside these all done from the web.config file instead of new code.


 


So what I did is I modifed the "Provider Toolkit" available from http://msdn2.microsoft.com/en-us/asp.net/aa336558.aspx and made a ParagraphProvider which has it's own configSection in the web.config file e.g.


 




  


     type="CustomModules.ParagraphConfiguration, CustomModules" 

    allowDefinition="MachineToApplication" />

 


 


 

  


 


   
     type="kevin.myModule.myClass, kevins_modules" />




   
     type="kevin.myOtherModule.myClass, kevins_2nd_modules" />


 


  

 


 


Now inside the default.aspx.cs file I call the instantiation of my ProviderManager with DoWork(strModulename, e.DataRow, e.Pageview) the ProviderManager then pases the parameters to the DoWork method of the Provider from the web.config file which has the same name as the strModulename parameter ex:


 


 


private void Content_CMEventHandler(object sender, Dynamicweb.Frontend.CustomModuleEventArgs e)


{


 


string strModuleName = System.Convert.ToString(e.Name).ToLower();


 


e.Output = CustomModules.ParagraphManager.DoWork(strModuleName, e.ParagraphRow, e.Pageview);


 


}




 


The problem for you could be that all providers must inherit ParagraphProvider and implement the DoWork method, and company a, b or c didn't know of my way of dealing with this issue so you'd have to make them add this small change to their modules.


 


But what Nicolai is talking about seems to be something along this way of dealing with this major problem, and I'm looking forward to how this issue is solved in the january release.

 
Nicolai Høeg Pedersen
Reply

Hi Kevin


 


Your solution to the problem looks very much like the one we will provide. It will not be needed to add something to web.config, but there will be a base class that needs to be inherited. It has one method that needs to be inherited and thats it.

 
Reply
NP wrote:


Hi Kevin




 




Your solution to the problem looks very much like the one we will provide. It will not be needed to add something to web.config, but there will be a base class that needs to be inherited. It has one method that needs to be inherited and thats it.




That would be perfect, 'cause we do not always have access to the web.config, especially in the case Peter is talking about.
 
Reply
ks wrote:

NP wrote:





Hi Kevin








 








Your solution to the problem looks very much like the one we will provide. It will not be needed to add something to web.config, but there will be a base class that needs to be inherited. It has one method that needs to be inherited and thats it.








That would be perfect, 'cause we do not always have access to the web.config, especially in the case Peter is talking about.


What can I say but "I'm looking very much forward to this ajustment" :)

 

You must be logged in to post in the forum