Checkpoint Q&A #3
Checkpoint Q&A #3
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 and welcome to check point Q&A 3,
where we will review some of the base concepts and talk about some of the
common pitfalls
and specific challenges that you'll find in the lessons running up
to this section, ok? So, for this
particular checkpoint, we are going to
see a little bit about the differences when we move
from the submit type of interaction with our screens,
to the AJAX paradigm, that you've been using in the latest
lessons. Also a
problem that people normally encounter when we move to Ajax
in the assignments that we have, is the disappearance of some of the validations.
So we're going to talk about what's causing this or what might be causing this, if
you're getting this.
As promised we're going to revisit webblocks
and now that you've learned AJAX and you've learned a little bit more about
the interaction with the
webblocks, we'll see how these webblocks can actually communicate
outwards and we're going to drill in to that mechanic
of the notification. Finally and just to wrap up
some of your knowledge, we are going to talk a little bit about
exceptions in the code, how they are handled, where they are handled
and effectively what effect this we'll have in your
transactions that might be occurring in the database.
So, to start of, let's recap a little bit
about what we have seen of the lifecycle of
the pages. So when we first get a page,
the first thing that gets born is the screen variables
and the preparation itself is executed,
where you normally fetch or otherwise calculate
the data that will feed the widgets that will appear on the screen.
Then the actual screen is rendered and sent to
the browser. We covered this, with a little bit more depth, in the previous
Once the user is looking at the screen,
he feels in the forms that might exists in the screen, and presses a
assuming that he submits this information
to the page, it ends up in a screen action
and once the screen action is reached by the request
the screen action variables are created and they are set to the appropriate values
and this screen action itself is executed.
Now, yesterday when we were talking about this,
and you actually get the end node
of this screen action, we discussed
what happens afterwards,
where would you go from the end node of the screen action
once it got reached?
And really what we said at that time is,
in the particular case of the submit, which is the default a interaction that we
have with screens and that's how the way it have worked
for many, many years exclusively,
was that, the end nodes cycles immediately back to the
again, it runs the preparation again,
and then renders the screen again. So the user
effectively gets the full payload of
the screen back in his browser. It was worth mentioning that
this cycle actually preserves the
variables, the current value of these variables,
so you can continue working on whatever values the user has already input.
Now on AJAX, as it was mentioned in the videos,
is actually slightly different. When you get to the end
node of your screen action, the execution stops
there and then, there's absolutely no
implicit cycle back to the preparation
and therefore there's no re-rendering of
the screen, ok? So let's bring up
the development environment and what we have over here was
the code that we probably had about the time of the checkpoint
two, so the previous one, where we have our button here,
which is of type submit, that goes into the screen action
GetAvailableRooms, it has the validation
it finds a room that matches those inputs,
saves it to the
the appropriate values to the form and on the end node it cycles back to the
the preparation gets executed, the screen gets re-rendered,
and that's how we had it up until the checkpoint
two. Now with AJAX this
screen looks slightly different, in fact it looks
a fair bit different, because we've been working in the UI as well,
but let's focus here on the button that is now of AJAX
submit. It goes into the screen action,
which is, as you look, very, very similar, but
here is the big difference, you have
these panels over here, ok? Effectively what's happening is,
since we know that upon getting to the end node,
we will not be doing anything else
because we got here via
a AJAX submit rather than a submit,
it is of utmost importance, that we're very, very explicit
as to what we want to be refreshed on the screen.
Anything that we miss mentioning, that needs to be refreshed,
will not have effect on the screen. So we can have all this
query being done, we can have this assign saving some of the outcome
of that query, to appropriate
variables that should have an impact on the screen,
but, if we actually do not send again,
for example, the information or the appearance of buttons,
we cannot count on the cycle back because it just does not happen
in a AJAX submit, ok? So,
this is the great difference in this mechanic. You have to keep an eye
on what happens, ok? So,
the layout of the screen actions that you reached by a submit,
tend to be slightly different of the layout of those actions, if you reach
sorry, if you reach them by a submit AJAX, AJAX submit.
They are not only slightly different from the ones you get
via the normal submit. It's very, very common that you need
to have a refresh of data, so it's
very common that you see the refreshed data and
node, which you can see here in this slide or otherwise
you assign the values directly to the widget
variables, as you normally do and then very important, do not forget
to call those AJAX refreshes upon
those affected widgets, ok? If you forget to do this,
you'll be changing stuff on the server side, but the user will not see anything
in his screen. This leads us neatly
to, why do sometimes, when people are doing these particular assignments, for
example the bookings,
they see their validations, which were working,
disappearing. Let me bring back the development environment
again, and here you will notice
that I actually edit something here,
that was not
on the older version.
Over there, you noticed?
It is nothing here before going in to the
last check of validation, while over here
I'm refreshing the form. The reason for this is,
our validators, the
little snippets that make those red markers appear, when you have anything
invalid, they are also part
of screen content, and they actually live next to the inputs,
ok? So this means that, for the negative
side of refreshes,
you will also have to explicitly send them back to the screen.
What I'm doing over here is, since potentially
the form will need to either show new
error validations or hide error validations, in face of changes in inputs,
it is very, very important that I also send back the form,
ok? That's the reason why I have here an AJAX refresh
of the form. It is so, that
any appearance or disappearance of validation messages,
get sent back to the browser
and the user effectively gets it feedback. So this is the reason why,
if you have seen those things disappear,
in your particular case,
it can be due to this, and therefore it's just a quick fix to actually
and that part of the screen, as well. Now,
as for moving on to the webblocks part,
let me bring up another module that you might be working on,
which is the CustomerSupport, to show you a little bit, here,
about the mechanic of the outwards communication.
So we have screen here that displays the high priority
issues of a particular customer application.
And in here we have a panel that
got a reference to a block.
Now, if you noticed, this reference to a block has got
an OnNotify
specification, here, and this OnNotify here
effectively is where
you specify which screen action
of the current screen, we'll be the handler,
will be responsible for catching any notifications
that are fired from within this block, ok?
Looking at this, at the block
that is referenced over here, somewhere inside it, has
at least one notification, that we need to listen to,
and if he notifies, we will
handle it on this particular screen action.
Drilling into the block,
we can see, this is the view of that particular block,
you can see a couple of buttons here, that are associated with
screen actions of this block, block actions, if you'd like.
If I double click here, when we click on the HIGH to assign
a certain priority to this issue,
not only do we do all the backend
stuff, of actually refreshing the data and refreshing
the screen, we're also calling this notify widget,
and by calling this notify widget, it's over here, we're
pulsing the screen
where this block is placed,
ok? So when we get to here,
we will get the notification
in our parents screen, where we were,
and this code, the OnNotify, now in the screen
will be executed, ok? And you probably noticed that when you first start
developing a block you don't actually need to specify this
OnNotify handler, this panel actually doesn't appear,
because it always shows up once the block has at least one notify
If the block has at least one notify widget, you definitely need
to specify a catcher, even if you're not
interested, really, in handling it.
You still need, it is going to be a mistake, an error effectively, if
I say NONE,
you will see that, TrueChange is telling me that
I would need to specify something, ok? You definitely need a catcher, a
if the block that you are referencing has
an notify widget. Normally the confusion that arises
on this is, people tell me, for example they are going to
some screen code and they want to use
the notify widget action.
Ok? We have... I am searching it over here and is actually
quite a usability tip, you can actually drag stuff from there to drop
to wherever you want, but you'll notice that I cannot drop
this one, ok? The reason why I cannot drop the notify widget is because, the
only makes sense inside the webblock.
What we're trying to do over here, if you look at
the breadcrumb over here,
is I'm trying to drag this to
a screen action of a screen obviously,
not into a block. So it doesn't make sense because
notifying is strictly a mechanic from block
outwards, ok? What normally people
might want to do, and it's worth mentioning,
is getting or passing some extra context
on top of
your notification, and a the way to do it is,
and sometimes people don't use it, is on the notify widget
you actually have a message here, which is just a free text parameter, so if you
to, in any shape or form,
add extra context to the notification over here,
you would say something like
"Set to High",
the notification will fire,
the screen where we have this will be notified
on that action, and if we wanted to retrieve
that context we could use,
a slightly different action, which is NotifyWidgetGetMessage,
and this one, yes, you can drag
anywhere, ok? And this effectively returns
the value that you passed on notify
from them webblock that has fired this notification,
ok? Very well, let's have a look here
at a couple more things to do, for example moving on
to be exceptions. Now,
if ever an exception gets
fired, where
and how do we handle it? Basically what we do is,
if a problem occurs in a certain action,
the platform tries to catch that error,
but close as possible to the error occurrence. So if there was an action in this particular,
an exception in this particular screen action, we will try to match it
to over here. Normally you get this created
for you, already automatically, but you can actually refine
or otherwise create more than one handler
in the same action. I'm going to show you here,
in the book room, I actually created one slightly different.
Let's see...
On this BookRoom, you'll notice
that I did a change there,
from the normal one, you see, All Exceptions
to Database Exception. What I did here is proposing
only to grab this level, Database Exception, which are more specific
than the All Exceptions, if you see the
tree. So locally in
this screen action, I'm only considering
grabbing database exceptions and handling those.
If I don't have a handler for the type of exception that was thrown,
the platform looks upwards to see
where it should catch things. So the next thing
up from a screen, will be its flow. So if we go to the flow,
we can see, here,
a section, I actually going to drag this down. That
is now wanting to grab a different exception,
say, just strictly the Abort Activity
Exception. Don't worry about what this is just, a different exception.
If the exception that we thrown was of this kind, we would get it
over here. Now what happens if all the way up
you don't have any catcher for the exception that you throw?
Well there is an extra functionality in the themes
that specifies what is
the handler for these uncaught
exceptions. If you go into your theme, you'll notice your error handling
flow, ok? So this is where the last resource
is, to handle a particular exception.
So we can see that the Common is the final handler.
So if we go into Common, we will see that,
if we didn't catch it in a more specific place,
closer to where it was fired, at least we will catch it
over here, ok? So this is the way
exceptions work, we try to catch them by type,
as close as possible to being fired, and keep going up, and up, and up,
very, very similar to how throws work in other languages,
such as C#, Java and C++, etc..
Now when an error occurs, normally the question that follows is, what
happens to the database
interactions that I've had so far? And this is the last point we're going to
mention today, is when you do a request
into the OutSystems Platform, a transaction is created for you,
at the very beginning of that request, ok? And at the very beginning of that
all the changes, that you start doing, create, update,
delete, they are executed on that transaction.
Once you successfully finish
that request, an implicit commit
happens, so you don't have to worry if you went through that
the good path, the commit we'll make sure that everything
ends up in the database. In case there is an exception,
by default there is a roll-back of everything
that you changed. This is to try to conserve
some sort of database coherence.
So by default, a handler, an exception handler,
we'll roll back your exceptions,
or will roll back the transaction upon an exception.
However, if you noticed you can actually change it over here,
so abort transaction, if you don't want to
loose whatever it is that happen, just click this
to No and this error handler, if it's
called, if it grabs your exception, it will do whatever it follows,
it will reach an end node, and he
rather than roll back, it will commit, has if it had
been a successful execution, ok? So,
that's basically it for today.
Great to have you and I hope that you keep enjoying the course
and you join me again for checkpoint number 4. Take care.
Bye bye.