Concepts for BIG OutSystems Projects (Part i)
# 1 - Time zones, Bionic Finger, and Naming Conventions
Overview
This series is a compilation of challenges, approaches, and solutions that were part of our path as OutSystems Developers throughout different projects. Keep in mind that many resources, tips, tricks, and techniques were also shared with us in various articles and forums by peers and colleagues. We decided to share what we have been learning in our journeys in the hope that it can also bring value to you.
As we face different challenges, this series will include various random topics. Stay tuned.
Time zones
Do you have users in different time zones?
In many projects, you need to deal with different time zones, as a user from Tokyo (GMT+9) will need to see different timestamps compared to a user from Moscow (GMT+3), using the same application at the same time.
Another challenging topic is how to deal with Daylight Saving Times (DST) that can vary from country to country and even between places within the same country.
A typical solution is to store the timestamp always in the same time zone (for instance, in UTC) across the application and convert it to the user's timezone only when showing the information.
A couple of functions should manage the time conversion with the purpose of:
Converting UTC to local time zone;
Converting local time zone to UTC.
Tips and tricks
Using a standard reference point like UTC will facilitate reading and developing the actions/functions that do the conversions.
Having the database, controller, and front-ends synchronized is simpler to manage and recommended to avoid unexpected behaviors.
Resources
The Bionic Finger
Do you know those impatient or stressed users that hit the save button several times in a row? Did it result in the creation of multiple records?
If you need to avoid this scenario, two different approaches can work in parallel to accomplish that:
Client-side logic
This solution works in buttons that use AJAX submit method, where we can add a piece of JavaScript to disable the button after being pressed. When the request is completed, the button will be enabled once again.
This solution has the advantage of being user-friendly by giving the user a clue that the button was already pressed, thus avoiding unnecessary clicks.
You can check the Button Locker forge component in the resources below to see an example of this JavaScript in action.
Server-side logic
Develop your code running on the server-side to prevent the creation of multiple entries with the same data. To do this, for instance, with a save button, you can use the built-in GetForUpdate action of your entity.
For more help handling Concurrent Updates on Application Data Records, visit the link in the resources below.
Tips and tricks
In the client-side example, you can expand the behavior across the entire application using CSS classes and apply the style to the buttons as needed.
Resources
Naming Modules and Applications
How easy is it for you to find the modules you need in your OutSystems factory?
There are approaches for naming modules and applications to help you find and manage them within your environment more efficiently. For instance, some of the best practices have for basis the use of English and meaningful names. Another helpful piece of advice is the use of suffixes and prefixes. Thus, accelerating the classification of the modules in discovery, as it can automatically classify the modules based on it.
By default, the only prefix set is "template_" for the application's templates. In all the other cases, the use of the suffix can identify the module or application layer. This is beneficial in managing and maintaining a solid and efficient architecture.
So, in this case, we usually use the prefix to distinguish between different projects and domains. For that, we can use the first letters of the names of Modules and Applications.
As a result, you can end up with applications and modules with this naming: CPORProductFamily_CS.
CP = Customer Portal - Identifies the first layer that can be, for example, the project;
OR = Orders [Domain] - Identifies the second layer that can be a domain of modules and applications inside of the project;
CS = Core Services - Identifies the Architecture Layer.
As you can see, the color selected for the module also follows the colors in Layers of discovery.
On the EndUser modules, you may need to break this pattern to facilitate the user's experience using friendly URLs. But we can keep the same naming convention on the applications that contain those modules.
Tips and tricks
The applications' naming can follow the same standard as the modules.
When managing deployments in Lifetime, it's easier to search for the applications and distinguish between the three layers.
When managing solutions in OutSystems Service Center, you can find the modules easier. If you break the pattern for UI Modules, you can install the SolutionManager from OutSystems Forge to locate all modules based on the Application naming.
Resources
Like this article? Share it:
