1

I've seen many post (for example, see https://stackoverflow.com/a/7363860/1378356) which state that ASP.NET User Controls (.ascx) were not intended to be used across different projects/assemblies. Rather, the right way would be to create a server/custom control.

My question is, how then was it intended for one to create a DNN Module? DNN Modules typically have an .ascx file which inherit from DotNetNuke.Entities.Modules.PortalModuleBase which ultimately inherit from System.Web.UI.UserControl.

Is this the correct way to create a DNN Module and if so will I experience pains along the way?

Community
  • 1
  • 1
as9876
  • 934
  • 1
  • 13
  • 38

2 Answers2

1

If you follow the "letter of the law" that is laid out in the linked post that is correct. However, in the case of a DNN Module the controls that you create, your .ascx files, are consumed by your code and simply loaded with DNN.

Given that you are the consumer of these, or your module, the deployment or change risks as outlined are not really an impact with DNN.

If you were to build a module, and then allow others to consume your controls that is where things get a bit tricky and going the route of a custom control might make things easier to consume.

(A good example of what they are talking about regarding the complexity of update would be the DNN TextEditor control. Given the root relative reference to "~/Controls/TextEditor.ascx" you have to trick VS to know what the proper type is for the control.)

But all-in-all, for a DNN based solution yes the .ascx is an acceptable practice.

Mitchel Sellers
  • 62,228
  • 14
  • 110
  • 173
0

If you start with the module templates created by Chris Hammond (Christoc.com) you'll be nearly pain free.

Joe Craig
  • 1,244
  • 1
  • 7
  • 7
  • Those templates may do the trick, but can you please elaborate on: Is DNN in fact breaking the standard of not having ascx's in another project, and if so, why, or not? – as9876 Dec 10 '15 at 15:31