Ahh yes, here it is:
Understanding the stakeholders ( roles ) involved:
1. The Core Framework - We would like to provide a consistent model for how the master module links to it's "slave" controls that also enforces some structure into how it is implemented. We would prefer this structure be consistent in functionality, security, and usability.
2. The Module Developer - Needs an easy way to implement navigation to slave controls. The developer should not have to be concerned with usability (unless they play more than one role, which is usually the case).
3. The Designer or Information Architect - would like control over the look & feel of the functional components and should be concerned with the usability. Note : I combine these two roles here for simplicity, but they are really two different roles which would compound the problems.
4. The Portal Administrator - Mainly concerned with the application of security. This role should not be concerned with the look & feel, or usability (unless they are playing more than one role which is usually the case).
5. The End User - Wants a consistent interface that provides the functionality they need through an intuitive use of buttons, links, etc. Should not have to be concerned with why functionality is not available where they would expect it due to restrictions or limitations of the framework.
So goals for #1 & #5 are right in line. As well they should be since the goal of #1 is to make #5 happy in the end. The problem #1 is faced with is that it has to go through 2, 3, & 4 to get there.
So a major question to answer is, "How can the core framework provide for the needs of the module developer, the designer, and the portal administrator, so that they can in turn easily deliver to the needs of the end user"?
One answer is to define clear and distinct interfaces between these roles. Let’s switch from calling these roles to calling them "layers" to distinguish their physical application in the system. We need something that defines the boundaries of the layers, yet allows (and even enforces) them to understand how they are separate but connected.
Enter the Container
The container is in the unique position of facilitating the inter-connectivity of these layers, but in its current implementation it has several limitations. These limitations are not due to bad design necessarily, but more because of the way the container has matured into its current involvement.
Some issues with the container as it applies to its function in the framework are:
1. The container is not aware of the role it plays in facilitating the inter-connectivity.
a. It cannot be controlled by the module developer at all.
b. The portal administrator has limited control over if it will expose it’s functionality to the end-user. For instance, when a portal administrator changes settings on the module like display print, syndicate, etc. they are really changing settings on an object within the container.
2. The container forces the Designer to share the role of the module developer and expose functionality for modules.
a. If the Designer leaves out the action objects from the container then the portal administrator can no longer expose the functionality to the end user that the module developer intended them to have.
3. The container forces the administrator to choose it based on if it will expose the functionality needed rather than just allowing it to be used based on it’s aesthetic appeal.
Some issues with the possible work-arounds:
1. The container designer can always put all possible actions into all of their containers, but then how do they provide for some feature that might be added later? Does the Designer of the container have to version their containers to match with a version of a module or DNN?
2. The portal administrator could always use just a couple of basic containers that contain all the functionality, but that would remove the primary benefit of the having containers.
3. The module developer could just avoid exposing the functionality through the container and apply the action items to the module itself.
A possible solution:
The interface between container and module could be more clearly defined and allow the module developer to control what functionality the container actually exposes to the portal admin (instead of have a finite set of admin settings that may or may not be implemented).
The UI could then have a Container Settings section under the module settings that exposed this functionality to the administrator, who would then decide if they wanted to display it to the end user. The module developer and the portal administrator would both still be at the fate of the designer at this point, so the container would have to have at least one “Required” placeholder for all of the actions that the module developer defines.
At that point you could take it one step further and say if the container does not define the required placeholder, that the framework will define it instead using a base container. This base container would have all the functionality implemented that the module developer had access to based on the version of the framework.
Conclusion
There will always be issues with the container unless some design changes are made to separate the presentation from the functionality.