Ajax and Reusable UI
Web Blocks and UI Reusability
This lesson is part of the Developing OutSystems Web Applications course.

Hello and welcome back. In this lesson we will be covering the ways that the
OutSystems platform provides to developers so that they can write
reusable UI. Now, when developing complex screens there are architectural and
work breakdown benefits in splitting working in more manageable blocks and in
OutSystems web development these are called web blocks. Web blocks
allow you to implement not just the UI but also the underlying logic that moves
the UI. To recap, what are the benefits of using blocks?
First you can use a chunk of UI design in several screens without repeating the
code. This has advantages in maintainability because you fix
something in one place it gets fixed everywhere, and much like in the code, you
can encapsulate and hide away the details of the inner workings of a
certain block. So how do we design a new web block? You create a web block exactly
like you would create a screen. You place it on the UI flow and you design
it by dragging any widgets inside. You can then use the web block by dragging
it inside a screen where you want to instantiate that web block. In fact you
can have web blocks placed inside other web blocks, you just have to be
careful because recursion is not supported. So if you have a web block A
that's got a web block B, this web block B cannot have A inside again.
Finally, it's important to note that these web blocks have their own
scope and they cannot implicitly see anything on the scope of the screen or
other web block where they are inserted. The way to get the needed
context into a web block is like you would do on a screen, to use input
parameters and once inside the web block, the behaviors and the ways that you
implement them are very similar to screens: so you have local variables, you
can have a preparation to do data
fetch exactly like you would do on a screen and screen actions to carry
out any activities associated with, say, links and buttons.
It's important to note that when you refresh a web block it will rerun its
preparation prior to rebuilding its visual content. Now if you notice, and in
the screenshot you have the preparation and the screen action associated with
the block, and if you look at the list of things you will notice that there are no
output parameters.
This begs the question: how can the screen that includes a block be made
aware of any interaction that the user has with this block? The way to do this
is via an asynchronous mechanic and this asynchronous notification can be
triggered via the Notify action. So at any point where in a web block action
you need to notify the parent you just call this Notify action. It's important
to know that this action can only be executed inside a web block. When you're
notifying you can optionally send back a message that will give context to the
parent screen. Please note that as soon as you place one notify call inside a
web block, all the instances of this web block will require a On Notify
Destination action to be provided. So every single place where this block has
been used, you'll need to go there and select a screen action of that parent
screen that will handle these notify calls. To better illustrate what's
happening, here we have a diagram that illustrates the notify mechanic. From
left to right in the web block someone presses the Save button.
This calls the web block action number two. As we are executing it you find a
notify call. This will look into the screen where this block is instanced and
it's number three and find out what is the screen action that handles this
notification. Upon finding this, it moves on to the
screen action (that's number four in our diagram) and runs it in the screen. So
therefore the screen can respond to an event that happened inside the web block. We
don't have the need for output parameters. As mentioned, the notify can
be accompanied by one parameter called "Message", that's a text, and here we can
see how the message can be passed about. So we press save,
we go into the web block action, we notify sending back the message "John" and upon
catching this notify on the screen we can use the action NotifyGetMessage
to retrieve, in this particular case, the string "John" and act accordingly. Only one
point remains to be mentioned. When designing a web block you have access to a
special widget called the placeholder. You can drag the placeholder into the
body of your web block and therefore you mark an area that is meant to be
designed later
wherever the web block is actually instantiated. So you defer the HTML
content of that section to the screen that then includes the web block. So in the
top screen shot you can see the editor showing MyPlaceholder Placeholder
and in the bottom screen shot you can see this block being used inside MyScreen
and that MyPlaceholder appears over there and that section is editable.
It works almost as if it was a hole inside my web block. And that's basically it for
web blocks and UI reusability. In a nutshell, select the sections of your
screens that you want to reuse, place them in a webblock, place these web
blocks into screens. If ever you need to notify the screen use the Notify action
and in the screen, if you want to get the message from the notification, use the
GetNotifyMessage action. And don't forget if there's sections of your web block
that you want to implement later, use the placeholders. See you guys in the next