Hi @Dusan Lazarevic,

This is a very long post with a lot of different points but I will do my best to answer them all.

First, I don't think you will find a single course on explaining how to build a perfect app from scratch.
You will find that the Learning courses from OutSystems are grouped in 'Guided Paths'.
One of them is the Becoming a Reactive Developer if you go through all of the videos you should have a good base for all your questions.

There are a couple of other paths that might help on how to build an app from scratch like:

But I don't know if it will have all the level of details you are looking for.

Now related to your other topics.

Styling Challenges: Responsive Design for Widgets

There is no 'one change for everything'.

For each type of widget you will need to define your classes.

As a suggestion I would say for you to copy the classes that you want to change from OutSystems UI to your _Th module and change what you need.

If you want to style something depending on the size of the screen you can also use the parent classes, .phone .desktop .tablet .

If you open your inspector and resize your screen, you will notice that those classes are added depending on the size you have:

Check this link for more info on how to leverage it and how to define different sizes for each class.

App Architecture: Balancing Convenience and Best Practices 

Related to the balance between convenience and best practices when talking about tables and services, you should always have at leat 2 modules for your app.

A Core Service module and an End-User module.

On the Core Service you will have all your tables and reusable server actions.
Those tables should be ideally exposed as read-only, and you can have different actions to expose the CRUD operations.

On the End-User module you will have mainly your screens.

You can check the Architecting Sustainable Applications guided pathfor a more comprehensive information about what to have or not in each module type.

Depending on the size and complexity of your project you can have more application and modules like a _Th module where you have most of your app look and feel, or a _Pat  module where you can define widgets that are agnostic to the business and define the css specifically for that widget in the webblock for example

If you are interested specifically in the Style Guide Architecture and how to define themes, css and etc in the correct way. Check this other course.

Related to the drag and drop of entities to create folders (Aka Scaffolding), it is not a bad practice at all. 

The only bad practice would have the table used for it exposed not as a read-only table.

Creating a Custom Sidebar: Overcoming Layout Limitations

For layouts, you can always define your own web-blocks with custom placeholders as well the same way you have the layoutTop, layoutSide and etc. 
The only downside is that it will need to do it from scratch.
Most of the times it is easier to adapt one of them.
If you need a sidebar for example, you can create a copy or a wrapper of one of the existing layouts and use the sidebar widget inside it, implementing the actions to open or close it only.

It is a long answer as well but I hope to have helped,

If there are any specific points you have questions on let me know and I'm happy to delve into details,

Cheers,
RR :) 

Thank you for your responses. I have already completed the Associate Reactive Developer course and certification. In my project, I have two modules: MyApp_Th and MyApp end user module.

The issue I'm facing is that the MyApp module does not have a login screen or exception handlers for handling situations where the user is not logged in. As a result, when a user is not logged in, they either see random errors on the screen or get redirected to a blank page.

If I were to move all my screens into the MyApp_Th module, it would work as expected. If a screen requires the user to be logged in, they would be redirected to the login screen within the common flow of the Th module. However, since the end user module (MyApp) lacks a common flow and exception handlers, I'm confused about how to proceed.

I understand that I can use the built-in login screen and exception handlers, but I'm hesitant to put the screens inside the initially created module (MyApp_Th). Any guidance would be greatly appreciated. Thank you.

That makes perfect sense, thank you! I just remembered that I'm having trouble figuring out where to place CSS. The most convenient approach is to put the CSS for a specific block into its own stylesheet, and for screen widgets, in a screen-wide CSS stylesheet. However, according to what I learned in my courses, the best practice would be to put all CSS inside the MyApp_Th module. 

Unfortunately, I find this approach very frustrating because whenever I want to change the color of a block or element, I'm required to publish the MyApp_Th module, then refresh the dependencies, and finally republish the MyApp end user module where my screens/blocks are located. It feels like I'm missing something; there must be a more convenient and easier way to handle these tasks. I would greatly appreciate any guidance. Thank you!

Hey @Dusan Lazarevic,

That is correct.

The CSS should ideally be kept on the Theme Module, the reason is that multiple end-users modules can share the same look and feel, so having the stylesheet on your end-user module wouldn't make sense in this case because you can't have side dependencies in the End User Layer of your architecture canvas:

This is the number 1 reason why the _Th module is kept in the Foundation / Style Guide layer and you should use it to centralize your CSS whenever possible.

The reason number 2 reason why it is done this way, is related to performance...

Every time you put CSS in a block or a screen, you are adding a new stylesheet file in your app.

Which may increase the load time of your screen (As the app will load more files in background instead of just one).

The downside of it is to always have to refresh the references as you said.

In your case, if you have a very specific set of CSS classes that are used only for your End-User module, and will never be reused by other modules, you can try to add a new theme styleshet on your module and use the theme styleshet from the _Th Module as the base team...

In the end you would have:

                                 (Using as base) 
EndUserModule.css         ->           ThemeModule.css

This way you can keep everything that is reusable on the ThemeModule.css, and implement the specific CSS for your end user module at the EndUserModule.css.

Avoiding having to always refresh dependencies this way.

Take a look at this documentation, it is something explaining the structure of the theme generated by a SaaS component called experience builder but it is a good example of what we are talking about.

Another good read is this documantion, it will explain how to customize themes and create layouts.

And also, when trying those more advanced scenarios is always important to remember that the stylesheets from different locations (Web-block, Screens, Theme Stylesheets) have different priorities when loading.

Check it here


Pay attention at the 2nd item which is the web-block specifically.

When you use define your css at a web block, it is loaded even before than the theme style sheet.
What can cause unexpected behaviors if you use it in the wrong way.

This is done this way, because CSS directly from web-blocks should only be used to implement patterns at the Foundation layer.

And those patterns can be overriden by the Theme for different apps.

So always try to use the stylesheets from your _Th module to centralize your CSS, and if you have something that is module-specific create a theme on your module and use the shared theme as base.

Let me know if it helped,

Cheers
RR :)