Designing extensible modules - best practices: Designing reusable Views

Designing extensible modules - best practices: Designing reusable Views

April 07, 2009 0 Comments

The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.

[This post is part of the developer's manual preview published on this blog. You can find temporary TOC here.]


When we wish to design modules that can be extended into different modules there are two basic areas we have to make sure are flexible and reusable:
  • Manager class (API class)
  • Views (UI)
In this article we are going to see what does it take to make Views (UI) reusable. The diagram below gives us a high level overview of what does it mean to design a reusable View.

As the diagram suggests, ideally, we would develop one View (called ReusableView). Given that it makes sense from the requirements standpoint, we would like to use that View in both Module1 and Module2 modules. Since we cannot know in advance where in module View hierarchy this View will be used, we should make the View hierarchy ambivalent - meaning that View can work at any level of the View hierarchy.


Somewhat connected to the hierarchy ambivalence is the host ambivalence. At the moment of the View design we do not know which View will serve as a Host for our Reusable View, therefore we should design the View in such a way that it does not matter which View is the Host.


Finally, we are not creating carbon copy modules, but rather modules that are very similar, yet different in certain details. Most probably, the template used by our reusable View will differ from module to module. In that aspect we also have to ensure that our View can work with different templates and different implementations of View child controls.


It is important to note that we will not be able to change absolutely everything (nor would it make sense - if we need to change everything - we may just as well create a new View). So for example, the crucial child controls that View is using to perform its function will have to be present in all templates. We will see, however, how we can take advantage of interfaces to loosen up these requirements.


In the following three articles we will explain and give code samples on how to achieve the goals we have set for the reusable View design:

  • Host ambivalence
  • Hierarchy ambivalence
  • Child control ambivalence

The Progress Team

View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Comments are disabled in preview mode.
Latest Stories in
Your Inbox
More From Progress
The New Mobile Development Landscape
Download Whitepaper
IDC Spotlight Sitefinity Thumbnail
Choosing the Right Digital Experience Platform to Improve Business Outcomes
Download Whitepaper
The Fastest Way to Build Mobile Apps With Cloud Data
Watch Webinar