Design Patterns in Smart UI

One of the reasons why Smart UI fascinates me is the way Design Patterns are used.  As you explore Smart UI code you encounter many of these patterns.  But what is a design pattern and why use them?

There are many definitions and variations of Christopher Alexander’s original definition, but the one that I liked is the following:

“A Pattern is a named description of a problem and solution that can be applied to new contexts; ideally, it provides advice in how to apply it in varying circumstances, and considers the forces and trade-offs. Many patterns provide guidance for how responsibilities should be assigned to objects, given a specific category of problem.”

In simpler terms, a pattern is a reusable solution that can be applied to commonly occurring problems without the need to code a completely unique solutions each and every time.  Design patterns are templates which, when applied, solve commonly occurring design problems through proven solutions.

MVC (Model-View-Controller):  Out of the many design patterns observed in Smart UI, MVC is the most important one. Without an understanding of MVC, if you start designing/coding in Smart UI then you are really asking for trouble. MVC addresses separation of concerns and decouples the business/domain data (Models), the presentation layer (Views), and the interactions (Controllers) between various parties (User Input, Model Changes/Updates, View Changes/Updates).

But why is this decoupling required and how does it help? Decoupling reduces spaghetti code. By doing so, it reduces dependencies; allowing separate development of user interface, business data objects, and the data flow handling. More importantly it helps code re-use. While the Model represents the data in an application, a View is the visual representation of the Model.  Finally, a Controller manages the communications between the UI and the data, updating the views when data (Model) changes and updating the data when the information within a View is changed though some user input/interaction.

A second variation of the MVC pattern also exists. Called MVP (Model-View-Presenter), it further decouples the Presentation logic from views and this acts as a Controller.

Smart UI neither applies pure MVC nor a MVP design pattern. There are no controllers in Smart UI (though context is a Marionette Controller, it is not the MVC’s controller). There are no Presenters either. All the business data in Smart UI is represented by Backbone Models and the presentation layer is implemented through Marionette Views. The Views in Smart UI play the role of MVC’s Views and also the role of the Presenter under the MVP paradigm.

Command:The menu actions in Smart UI are implemented through a Command design pattern. The main idea behind the command pattern is that it provides you a means to separate the responsibility of issuing commands from that of executing them, delegating this responsibility to different objects instead. To achieve this separation, the designer creates an abstract base class that maps a receiver (an object) with an action (a pointer to a member function). The base class contains an execute() method that simply calls the action on the receiver. The core implementation of Copy /Move/Reserve/Initiate Workflow, etc are all carried out through Command design pattern. Copy/Move/Reserve Actions are actually all concrete Command implementations. So the function menus in the Classic UI, are now encapsulated as Commands.

Mediator: The heart of all the Smart UI components (from my perception) is a Context object. If we dig more into the definition of this module, anyone would surely get the shock of their life. The declaration says it is Marionette Controller. However, if you view to the latest Marionette library code or the documentation, you will not find any information relating to this controller – it has been deprecated. With all your new-found MVC knowledge, the inference would be that it could represent a Controller. But it actually has nothing to do with MVC and is indeed an application of the Mediator pattern. The Mediator pattern defines an object that encapsulates how a set of objects interact. Mediators promote loose coupling by keeping objects from referring to each other explicitly and letting you vary their interaction independently.

Factory: Creates objects without exposing the instantiation logic to the client and refers to the newly created object through a common interface. Most of the models and collections in smart UI are created through Factories.

Observer : Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. For example, the breadcrumb panel is an observer and gets updated as the current folder/container changes. Similarly the filter panel is the subject and whenever a filter is changed the browse widget observes it and shows filtered data in response.

Decorator: This pattern adds responsibilities to individual objects dynamically and transparently, that is, without affecting other objects. For Example the perfect scrolling or infinite scrolling behavior can be added to a view or widget without actually writing the code in the View definition. This helps code re-use and decorates the view with the behavior.

There are more design patterns observed in Smart UI but the intention of this article was never to actually list everything or write in depth details, about the design patterns. It is about sharing part of my journey and inspiring others. If there are other things that you would like me to write about my Smart UI SDK development, reach out to me directly or add a comment to this post.

About the Author

Siva Salipalli is a Solution Architect and OScript Developer with Fastman. He is experienced in Web Reports, Builder, CSIDE  for Livelink 9.2 to Content Suite 16.2 and  OpenText Smart UI SDK for Content Server 16 and Content Suite 16.2. He has worked on solutions such as Fastman Permissions Manager & other custom modules for partners and customers.