Checkpoint Q&A #2
Checkpoint Q&A #2
This lesson is part of the Developer Online Class for OutSystems 9 course.

Here you can review some of the main concepts and get help on common problems and challenges faced by students when going through the previous chapters.

NOTE: You may have already watched sections of this session if you followed any of the "further information" callouts in previous lessons.

Hello again and welcome to check point number two.
We will review some of the basic concepts and talk about some of the common problems
and specific challenges of the lessons that are running up to this particular
So on this checkpoint we're going to
cover and recuperate again the
life cycle of the page, how variables get injected
into a scope and be made available to be used.
Once we actually have a page rendered and available in the browser of the user,
how we can navigate away from it
or submit back to it and how they work differently.
Then we're going to see how some of these variables,
even though they're available to be used, you have to be
careful about using them, because they have with them costs,
so there's going to be a performance tip in here. Finally we are
going to check the input validation, just going to recuperate one doubt that
normally appears about validation, server side validations,
and finally talk about webblocks
and how and where they can be used.
Now when you do a request to a web page,
what happens? The first thing that happens is
any variables of the screen are born
and they are born either with parameters
in case they are inputs, they
will be bound to any arguments that you might
pass or indicates a local variable that is started up
with a default value. So these variables immediately
are born and available to use from the get-go of your preparation.
Then you go in to your preparation, which you already know by now because to be
implemented quite a few,
where you develop normal logic
and database queries that retrieve values for you
to use and to seed the widgets that will be on your screen.
Finally you'll get to the part where you actually render screen,
render the widgets in face of the data that you obtain
in the preparation. So let's now look at
how the several variables
come into being once inside one of these requests.
So have a few samples here, whereby,
I've got a simple page, it's got
an input, a local variable and the preparation.
Now the preparation calls several
reusable actions that you know already. It's important then
to verify what is available to be used
at each of this points, as we go
through with the flow of execution, in this preparation,
leading up to the screen. At this particular point,
if we see what's available, you'll realize,
that, yes the variables as mentioned are available, the variables of the screen
because they're
always available from the very beginning, plus
the output of this action, which we have already
ran past, so this action was executed,
it's reusable actually, was executed and injected into the scope,
its output and it's ready to be used over here.
Then we get to a branch where we either take
the left hand side or the right hand side. In here
it becomes more interesting. What is available
over here, if we take the left hand side?
Very well, let me close
this and see what's available
over there and now we'll see
that, as we expected, the screen variables are here,
the common action is available and also the last action,
because the platform has determined that you definitely have run both the common
and the last action so those outputs are available over there.
What happens over here then?
In this assignment in the right hand
side of our flow, looking
at what's available you see that, we see the right action
but as you probably expected by now, we cannot see the last action,
because we definitely have not ran
the left action, when he took the right branch.
Finally what happens when we rejoin
and we get to over here? Now
what's available to be used over there
is the screen variables, the common action at the top
and only on top of that common action, this common join action.
Neither the last action or the right action
are available to be used. The reason is
that at design time the platform does not
know if you taken and the last action
or the left branch or the right branch.
So it is conservative over here, meaning, only the outputs
of actions that it is sure that you have run,
we'll be available for you to use, ok?
So this is the rule: you collect the outputs of actions
as you visit it and only see the ones you have definitely visited.
Now for the second sample over here, I've
added queries to the preparation.
So quite similar but with a couple of queries.
If we look at what's available over here,
you see an interesting thing. Yes
the screen variables are there, yes, common action is there
as well as the aggregate that we have visited,
but surprisingly you will see that
this last aggregate, which is actually going to
only be visible or executed in the
future, is already available.
And the reason for this is
one of simplification of the preparations. It was designed like this,
so the queries, both aggregates as they are the case over there, but if you
SQL queries, would be exactly the same, their
output variables, their lists
are visible everywhere in the scope,
where they exist. Now what happens is,
if you were to try to look at what list has
before you actually executed, you will just find
that it has no records, but
it is available to be used. The reason for this
is, as I mentioned, to simplify what is then available,
once you come to the end node and you move on
to render the screen, what's available to be used
by widgets.
On this third sample, I actually added some widgets
to the screen. The preparation you are going to see in a
second is exactly the same one, but we now have
a form widget and
a table records widget, which you've seen
when you were using the development environment, these major
widgets have variables of their own, somewhat
prime but variables of their own. So,
they're bound to whatever sources
created or made available in the preparation, but they themselves also inject
variables into the scope. Question here is
when are these variables born? The variables of
the widgets. Let's have a look at
this preparation, looks exactly like the previous one,
let's have a look at what's available here? It's a very similar scenario
of what's available from, both screen actions,
screen parameters, variables, the action we've executed
aggregate we've executed, the aggregate we have not executed yet
will be empty, but here, this small folder widget, we can see
that the widget variables,
the record for the form or the list
for the table record are already available, ok?
This is strictly because these
variables of widgets are considered
screen variables, so therefore they are born together
with the normal ones we associate
at the very beginning, ok? These become
available immediately, so this is how you
flow through things and how the outputs become available
to be used, either in actions
in the flow further on or in the case of a preparation
in the screen rendering. Now
let's actually look at the fourth example,
which contains interaction with the page.
So we have a link here, which we
set to go to the current screen via navigate. What happens when someone
follows this link?
This we'll actually, restart
the request to this screen, completely new request,
all the values that the variables of this screen might have
are reset according to the rules we
seen and we discussed,
so arguments that you passed in or default values.
More interestingly though, what happens if you press the submit
that by definition goes into a screen action
of our screen?
Well, screen action
life cycle is very similar
to the initial part of the first render of the screen.
Any screen action variables,
pay attention, it's not the screen variables but screen
action variables, private variables to this screen action,
are created first and the logic on that screen action
is executed, ok? So this means
that if we go back to Service Studio,
clicking on this is going into submit,
the submit action has got these two screen
action variables, if we go into the submit,
let's see what's available here
and we realize that, yes we see the
variables, both of the screen, these two,
and of the screen action, these two
over here. Plus the outputs that we have visited
reusable action calls, the output as exactly by the same rules
of any queries that exist in this particular
screen action, the widget variables
are here, plus the preparation outputs are here as well,
ok? This means that in a screen action
the server strives to emulate, as if
you work just continuing the initial
interaction with the screen, and here comes the
word of warning that I mentioned in the initial slide.
Just because the outputs from the preparation are available in the scope
and you can use them with no mechanical problem,
does not mean it's a good idea to use them. The reason for this
has to do with the way web servers work
and this is not specific to the OutSystems Platform. The thing is,
if you use something from the preparation in the screen action
that value needs to be
persisted across, so we can be reconstructed on that screen action,
upon the execution of the action, and
the place where this value is stored,
is the page itself, its hidden in the page.
This means, if you use this output from the common action,
which was in the preparation, if this
output is a particularly heavy variable,
this is going to have a major impact on the weight
of your page, because it needs to be hidden there
to be used later. So it's normally
a best practice, if you need to
use values from a query that you use on a preparation
or values from an output that you use the preparation, it's normally better
just to redo the query in the action,
because stretching from the database is much much faster
than reconstructing and having very heavy
on your module, on your application.
Finally to tie up the
submit mechanic, is what happens when you get to the end node
of the screen action? Very well, if the screen action was called by a submit,
this end node immediately
takes you implicitly back
to the screen preparation, to run the preparation again,
but maintaining whatever the context of variables,
including widget variables, that
happen to be the case
in screen action, ok? So you go around again,
you will re-run the preparation, you will re-render the screen
and the user in his browser
we'll believe he is left on the same page.
The difference between the navigate and this end node that wires directly to the
to remember, is the
navigate will reset the variables
as if it was a completely new request because that's what it is,
while this wiring of the end to the start node maintains the values
of the variables, it just re-runs the preparation, ok?
It is quite important this difference in the mechanic.
Now, validations. If you remember you implemented validations
here in the bookings page. It has
a button of which you have changed the validation from
client and server just to server. This means
that the client side validations, that can be done automatically,
by javascript in the browser, blocking the submit
will not be done in the browser. These validations,
all validation in fact, we'll be done server-side,
so the request will always go through even you feel
feel in invalid values your inputs.
Now once you get to the actual target of this
button, which is the get available room,
you probably implemented something very similar to this,
which is this validation area. Now, normally in this validation area it looks
very much like this, like a saw with teeth,
where you check for one particular
business logic requirement of validation and if
that assessment is correct,
that assertion is correct, you move on. If not
you flag that input as invalid by
setting it's valid to false and also by associating a message,
that will then appear on the screen, you keep going for all the
necessary logic steps, that makes sense in your particular
case. Finally,
and this is normally the pattern, is you need to double check, has
any of the validations failed, just one
final checkpoint, is any of the validations failed,
and the way to do this, to recap, is to check
the form valid. If the form valid is true, it means that
all of its children inputs are
valid and therefore you can just move on
with the positive path of your
screen action. If any of the children,
inside the form, are invalid, you should
then bailout and not continue.
Normally the question that arises here is, since I've disabled the client side
we'll I need to explicitly code validations,
such as these, for the mandatory and
for the wrong type values
and inputs.
The answer is no, even though
by moving away from client-side validation
to just server validation we stop
making these validations, in the browser
when you come into the action, those fields
that where either mandatory and had no content typed in,
or were of a certain type and what was typed in
is of the wrong format, say you type in a text where you are expecting
an integer, these inputs are going to be
pre-invalid, ok? So like
this one here, the .Valid
property will be false, already for you, so you only really need to code
the explicit validations which
are not specific to either mandatory not being filled in
or wrong type of value being typed in,
Now, to wrap up, let's have a look
at webblocks and reusability of webblocks. In our exercises
we've been using blocks inside screens,
and it is a misconception, let's actually
give you an example here, so, I have an webblock here,
which I'm going to drag into this screen, and
this block has got inputs, so I need to pass in
some context
and when we're rendering
this particular screen, we're going to
when he gets to the block, we are going to hand over the rendering
to the block, it will run its preparation
so it can set up what it needs to render itself,
it will render its part and then come back to the screen and the screen
itself continues rendering. Now it's normally
misconception, that you can not have blocks inside blocks,
you can actually have blocks
inside blocks. So, over here I'm opening
the outer block and if you notice I can
perfectly drag
another block called in a block into the outer block,
ok? This one will require another parameter,
and now our outer block
includes inside of it the inner block. If we go and see
the screen that includes the outer block, will now see that from the
viewpoint of the screen,
the outer block actually has the combine
content of both blocks, ok?
So there's nothing keeping you from including a block
inside a block and you can actually place blocks inside blocks up to the depth
that you want, ok? You can have a block inside a block, inside a block, inside a
block, inside a
screen. The only restriction that you're subject to
is, on these inclusions you can never have
a recursiveness, so a block
chain can never include a block that's already
part of that chain. What happens when you do that,
to remember outer blocks includes the inner block, if I drag the outer block
into the inner block, therefore creating a cycle, I'm warned
by development environment, that this is not a valid scenario,
ok? Because it could not recursively render this controls
and that is the only limitation that you have in inclusions or blocks,
ok? Just to
finalize and as a little teaser,
you have seen that the communication inwards with the block is via the
but blocks don't actually have
output parameters, you can see. You will see later on
in lessons further on, how you can communicate
outwards from a block to wherever it is placed,
but as for today this is all. I hope you're enjoying the course
and I look forward to seeing you on checkpoint three.
Take care, bye bye.