Story of Stuff

I've come across Story of Stuff again. This time I'm gonna make sure that more people are going to watch it. If you haven't seen it, this is a 20 minutes of fun filled video with a very important message. I'm positive that you won't regret this 20 minutes.



http://www.storyofstuff.com

This is a similar style video on carbon emission reduction plans. This method of 'CAP and TRADE' is apparently supported by Obama as well.

HTML Editors in DNN Modules

You might need to include a HTML editor in a particular module as a mean of providing a good content editing experience to the users. There are many very good commercial options including CuteSoft. I needed a free option and the most straight forward thing I could find is to use the DNN default text editor it self.

DNN 5 by default uses the FCKEditor. However it is integrated under a flexible provider model which allows developers to plug in different HTMLEditors (even commercial ones) without changing the core modules.

So things looked pretty straight forward and I just had to use <dnn:texteditor> markup (A control which was introduced with the above provider model enhancement) within my module (ascx file) to include the HTMLEditor control. And here lies the problem. The <dnn:texteditor> markup actually boils down to a control named 'TextEditControl' and the steps to include this is no different to general ASP.Net way, which is using Register Directives on top of the page/control;

1. Reference the relevant assembly (<%@ Register TagPrefix="ControlVendor" Assembly="AseemblyName" %>)

2. Add a reference to the control (<%@ Register TagPrefix="TextEditor" TagName="header" Src="Controls/ControlName.ascx" %>

(There's a better way proposed by Scott Gu here)

Now the problem with TextEditControl is that the same control (name) can be found in 2 DNN assemblies. Worst part is these 2 are different as well. I think one of them is a residue from previous DNN versions or may be they actually have real purpose. But why the hell can't they name the controls differently?

The proper one to use in this instance is the TextEditControl from 'DotNetNuke.UI.UserControls'. So make sure you refer to that assembly in your module (ascx file).

So it was hard toiling for a few hours before I caught this and it once again emphasized the real need of good documentation for DNN.

Some more tips on TextEditControl

1. How to create it programmatically

2. DNN Text Editor issue on Module Settings Page

Page vs Front Controller

MVC has been a tried and tested method of structuring your applications for a long time. Generally MVC mainly focuses on seperating model and view and less attention on the controller. Specially in rich client applications the view and the controller tends to lie close together. But in web applications this seperation is more critical since the view is essentially happening at client side (browser) while the most of the controller sits in the server side.
There are 2 basic ways of structuring the 'C' of the MVC, i.e Controller. The 2 basic methods are the Page Controller method and the Front Controller method.

The Page Controller is the more simple and straight forward way. Every request to the server is directed to a page (controller) of its own.

Under the Front Controller all requests will reach a single controller and it will dispatch the task to appropriate command class.

Let us analyze the 2 methods with respect to several aspects.

Criteria	Page Controller	Front Controller
Complexity / Ease of Implementation	Low complexity. Suits simpler web applications. Most of the time the commercial web application frameworks have built-in support.	Complexity is high compared to page controller. The single controller it self can be complex. However many CMS frameworks have this built in. (Eg: DNN)
Code Duplication / Code quality	Duplication can be high as the application grows. Has to implement a BaseController from which all page controllers extend.	Low code duplication. All common tasks can be put inside the front controller
Testability	Can be low. Has to go for a 2 part controller where one is HTTP dependant and the other is independant and testable.	The front controller will only handle transfer of the request to independant commands which could be testable. Has to be careful
Adaptability/Flexibility	When the pages of the web application is very different from each other, the code duplication can be higher. If you try to counter this with seperate inheritance tree, it can grow complex soon.	Since the front controller is centralized it's highly configurable. That's why many CMS frameworks use front controller to increase flexibility.
Performance	No extra bottleneck if plain page controller is used. However if a deep inheritance hierarchy is used performance can be a bit lower than normal.	The single front controller can end up being a bottleneck since it answers to all requests. Should avoid doing I/O or DB calls in the front controller as much as possible.
Thread Safety	The same page controller instance might handle (Depending on the web application framework, eg: ASP.Net) requests for the same page and thread-safety has to be considered. Use of static instances might be problematic.	Front controller can instantiate new command objects for each request and ensure thread safety at controller level. However model code still has to be thread safe.
Work distriubution and responsibility	Easier to distribute the work among developers since each area of work can be done completely seperately	Each developer has to have a good understanding of the Front Controller behaviour as everything depends on it.