When to use CreateChildControls() vs. embedding in the ASPX

Question

I'm developing a webpart for SharePoint 2007 and have seen several posts that advise to do all the creation of controls in the code-behind. I'm transitioning from Java J2EE development so I don't have the platform history of .Net/ASP/etc.

In other places it shows how you can do the same thing by embedding the control definition into the asp page with tags

My question is this:

What is the rule governing where to implement controls? Has this rule changed recently, ASP vs ASP.Net or ASP.Net MVC maybe? Is this advice limited to SharePoint development?

Answer 1

I am going to key off the fact you are developing a Web Part for 2007. Web parts imply you want to give users the ability to add the parts to pages as they wish. To implement a web part, you then need a stand alone DLL that is either deployed to the bin directory of the SharePoint IIS application or the Global Assembly Cache.

Generally with SharePoint, you do not HAVE an ASPX page to embed controls within and make it reproducible. ASPX pages will get created by users or features, and users will then add web parts to these pages. SharePoint is essentially a virtual file system, with many of the ASPX page either living in the database or in the SharePoint root folder making code behind a non-trivial task.

The web part needs to be deployed as a stand alone DLL file. Given the way web part development is, you do not have a design surface to create your user interface, so you need to create your control tree via code, with the preferred time during the lifecycle being the CreateChildControls section (see the earlier link).

There are some other ways around this such as Son of SmartPart (http://weblogs.asp.net/jan/archive/2005/11/22/431151.aspx), which allows you to create a User control and then you load the user control into your web part control tree. This is essentially the approach Microsoft took in 2010 with their Visual Web Part functionality.

The vast majority of the Web Part development for SharePoint uses the same Namespace as ASP.NET development, so if you are not doing SharePoint specific functionality within your code like list reading, etc, the web parts should be usable in both ASP.NET and SharePoint environments.

John

Answer 2

here are a few thoughts.

Dynamic control creation (inside CreateChildControls()

• this is a more dynamic solution
• if control layout needs to be different for say, different users, you have more control of the flow. Meaning you can embed controls within different trees, or tree branches, vs just making them visible/invisible
• may be more suitable if you need to make control instances accessible from outside of assembly

Declarative Definition (ASPX)

• Indeed more MVC style of doing things.
• This is the recommended way unless you have a reason not to (perhaps for above reasons)
• MUCH easier to maintain the UI components and Layout
• you could also make re-usable user controls in declarative fashion by creating ASCX files

you could also mix and match.. Declare some static elements, and dynamically sprinkle in others as needed by adding them inside a Panel control at runtime.

another common approach is to sublcass common elements (such as TextBox, or data grid), and modify how this control behaves, looks, and/or renders (by overriding Render event). Than you can simply use your version of the control inside of the ASPX. This is a win/win because you get maximum control while still separating layout from business logic. I always subclass in order to embed common functionality such as uniform look of all controls, personalization etc..