Good Morning!

Currently working with the platform in version 10.0, we encounter a problem between architecture and the use of outsystems accelerators. When an aggregate is used in the preparation of a web interface, we bring row-level filter logic into the page, spreading it out (between pages) and creating a higher level of complexity for maintenance.

In this scenario what would be the best architectural design, and since I centralize the logic of searching this data in a server action, I would lose the platform accelerators. Such as creating automatic tables and forms, using automatic paging and sorting and etc ...


Att,

Marcos Paulo Souza Miranda

Hi Marcos,

You raise a good point, and this is a choice that must be weighed, whether you

  • Duplicate row level logic and take advantage of the acceleration capabilities or
  • Encapsulate row level logic, and give up the acceleration, as well as the database optimisations.

Like all good architectural considerations, the pros and cons must be weighed.  I have chosen each of these in different scenarios.

Unfortunately, there is no easy answer.  It is an issue with platforms such as OutSystem, where we need to work with the platform to get the most of the advantages it offers, and be aware of the limitations that brings.

This probably is not as clear an answer as you might have hoped for, but I hope you find it helpful.

Kind regards,

Stuart

Stuart Harris wrote:

Hi Marcos,

You raise a good point, and this is a choice that must be weighed, whether you

  • Duplicate row level logic and take advantage of the acceleration capabilities or
  • Encapsulate row level logic, and give up the acceleration, as well as the database optimisations.

Like all good architectural considerations, the pros and cons must be weighed.  I have chosen each of these in different scenarios.

Unfortunately, there is no easy answer.  It is an issue with platforms such as OutSystem, where we need to work with the platform to get the most of the advantages it offers, and be aware of the limitations that brings.

This probably is not as clear an answer as you might have hoped for, but I hope you find it helpful.

Kind regards,

Stuart

Good morning, Stuart!


Thanks for the answer, we had already raised this same strategic line here. However we think of trying a third party opinion in order to understand some new possibility available by the platform or that has worked for other scenarios.


Att,
Marcos Paulo


Marcos Paulo Souza Miranda wrote:

Good Morning!

Currently working with the platform in version 10.0, we encounter a problem between architecture and the use of outsystems accelerators. When an aggregate is used in the preparation of a web interface, we bring row-level filter logic into the page, spreading it out (between pages) and creating a higher level of complexity for maintenance.

In this scenario what would be the best architectural design, and since I centralize the logic of searching this data in a server action, I would lose the platform accelerators. Such as creating automatic tables and forms, using automatic paging and sorting and etc ...


Att,

Marcos Paulo Souza Miranda

Hi Marcos,

I understand there are some pros and cons while using accelerators but this is what makes OutSystems a good option for fast paced development platform.

For brining row level filer in the page, another better approach you can follow is instead of brining it to screen prepration create a reusable web block in your Core Layer of 4LC. There you can use aggrigate in web block prepration and using the same web block on all other places where you want same logic and UI. This way you will be able to keep code more manageable and still being able to get benefit from outsystems accelerator.


Hello Marcos,

You can start creating the pages using scaffolding, and thus taking advantage of the facilities of the platform, and after the skeleton of your app is done, you make the entities read-only, create your wrappers, and replace the now missing "entity actions" by your wrappers.

Regarding "centralized" data fetch, you will have a bigger problem than the pagination and so on, as this could be solved by input parameters in the Action, and using "local lists" to store the results (in order to be able to refresh data, etc). 

The problem is the automatic optimization that the platform does when it knows where the aggregates will be used, something it can't do if the data fetching is done in an Action. 

So, I would say the most usual approach is to use aggregates to fetch data, not centralizing this, and using entity wrappers to take care of the security, but only after scaffolding.

Cheers.

Good Morning!

Thanks for this answers. I make continuos invetigation more options/alternatives for my problem.


Att,

Marcos Paulo Souza Mirnada