4LC question: 2 responsive module in 1 app sharing common uiflow

4LC question: 2 responsive module in 1 app sharing common uiflow

  

When I create 2 responsive module under 1 app to separate development/publish load (we have concurrent publishing issues very often) for big project with many developers.

Those 2 responsive module shared a Common UIFlow (Menu, Login screen, Invalid Permission, Header, etc) and I think shared a theme too.

Those Common UIFlow and Theme are in the first created module.

The second module references it.

I know this violate 4 Layer Canvas for UI side dependency.

How to apply 4 Layer Canvas correctly in this scenario?

Thanks.

Hi Harlin


You could create a third module Theme_Core which would be part of the Core layer. You could design both the theme and the Common Flow (Menu, Login, etc)  and import those to your End User Layer modules. I believe that would solve that circular/same layer dependency while still promoting code reuse.


Side Note: I recently came upon this awesome Forge Plugin to quickly create you app's 4LC on a web app and export it to image etc. Highly recommend it.


Regards

 -CLSJ

Thanks I'll try it.

I don't know that a UI element can be made into Core layer. 

I thought only entities or structure or logic is valid for Core layer. 

Solution

Harlin Setiadarma wrote:

When I create 2 responsive module under 1 app to separate development/publish load (we have concurrent publishing issues very often) for big project with many developers.

Those 2 responsive module shared a Common UIFlow (Menu, Login screen, Invalid Permission, Header, etc) and I think shared a theme too.

Those Common UIFlow and Theme are in the first created module.

The second module references it.

I know this violate 4 Layer Canvas for UI side dependency.

How to apply 4 Layer Canvas correctly in this scenario?

Thanks.

Hello Harlin,

This does not violates the 4 LC rules.

What you have is a "Theme" module, with higly reusable and generic UI elements (menu, login, global OnException handler, theme, etc). These are not "business" concepts.

In the 4 LC hierarchy, this module is a LIBRARY module.  

You just need to be careful to not create circular references because of the menu.

Cheers.


Solution

So, it is better to use external url link in the menu, instead of screen destination? 

Thanks. 

Harlin Setiadarma wrote:

So, it is better to use external url link in the menu, instead of screen destination? 

Thanks. 

It's the approach I use. The problem with this approach is that if you change the page name, you have to update the Menu.

A possible workaround is to use Entry Points for all pages with fixed names.

Cheers


You could also database the menu.  Put the menu names and the entry points in a core entity and use that to build yor menu.  You could even use a run on publish timer to automaticaly register the pages into the entity 

Is it also possible to split a big module to several module using webblocks?

So I will have 1 main module with screens and processes with human activity (destination to screen), and I have several sub modules containing only webblocks that is referred to main module.

This does violate UI side references, but no cyclic reference and not much change/refactoring needed.

Any inputs on how good or bad this idea is? 

We class shared webblocks as a core layer. They have UI elements but only as a shared service and if you treat them as a sub layer within core but just above core business logic then you should have little issues, 

This might be a bit of an overkill for you but this post covers the way we work by splitting the 4 layers up a bit further. 

https://www.outsystems.com/forums/discussion/35932/outsystems-code-documentation/

https://www.outsystems.com/forums/discussion/36009/data-entities-in-cloned-application/#Post128857



If I have BPT module that call screens from multiple module, is the BPT module considered as Orchestration Layer?

Harlin, I would say so :)