How controller modules could save your SAPUI5 project

Introduction

Have you encountered a huge amount of lines of code on your SAPUI5 controller? lots of events? functions? In today’s post I will discuss how controller modules help you.

The Controller Problem

The controller file handles the logic for the views in a SAPUI5 project. Just like in any other programming language, the tendency to overload and write bloated programs is evident to SAPUI5 controllers as well.

Controller
Controller

Usually a SAPUI5 project will have one-to-one relationship between a view and a controller file. Though developers can freely reuse a controller in rare cases. This creates problem for views that has complex layout and have many event driven design. More events and controller usually results to more functions and logic.

Centralize code are harder to maintain since you can mess up the whole application. If the source code is centralized, you may accidentally modify values that is shared throughout the controller.

You will also have monolithic logic, which are bound to the view. So whenever you create a new view, you might need to copy paste everything and have redundant code.

Huge controllers also prevent you to have polymorphic design. Separating the modules can open up the benefit of changing run time objects, example parent-child controllers.

Huge line of code foot print is also possible downside of single controller file. Since SAPUI5 loads Javascripts files that relevant to the current view, if you have functions that are not yet really needed, they will impact network traffic. Since these functions are already part of the controller being loaded.

The solution

Split the controller to smaller chunks of modules. Similar to how a formatter file is loaded.

Formatter
Formatter

Define the dependency

Modify the views references

Create the Module

In summary, this reduces redundancy. Promotes grouping of related logic to correct modules. It also promotes possibility of reuse and dynamic content.
This approach helps a lot when our application becomes big. This limits the scope and code change need for upgrade. So in the future release the project becomes manageable for different developers as well.

 

What other approach are you using in your project? Do you find this approach helpful? Let me know what you think, leave a comment below.


Leave a Reply