Hello and welcome to Ajax Interaction in the OutSystems platform. If you haven't
gone through the first two lessons covering the screen lifecycle please do
so before proceeding.
Now, in the screen interaction lesson we covered how the page behaves when we do
a normal submit to it. To recap, all of the inputs are passed in the request to
the page, the associated screen action is run and when it reaches the end statement,
execution cycles back to the Preparation, runs it completely and reveals the whole
screen sending it back to the browser. So how is Ajax different from this? Ajax allows
web pages to change content dynamically without reloading the entire page. This
is the important difference. So why would you want to use Ajax? Well
basically you're improving greatly the experience of the user because exchange
of the data with the server is very small, very quick, and it does not
affect the interaction that the user is having with the screen. So how does it
work? It works by sending a request that is however very short, there is no
need whatsoever for the whole response to come back, and the page state is kept
very much like in the submit. So how do you enable Ajax usage in OutSystems?
Well there is a third method by which your buttons or your links can be set to
communicate with the server. If you select Ajax submit you will be
leveraging the Ajax paradigm.
So what changes when you do an Ajax submit? When the End node is reached on the
screen action that is called it's worth noting that the Preparation is not
re-executed,
that's the main difference. Only parts of the screen that you explicitly tell
to the server that you want sent back will be part of the response.
This means that if your interaction with the screen, your Ajax interaction
with the screen, only really needs to update a small panel - say the top right
hand corner - it can do so very, very quickly. So how do you signal
the need for the refresh of a certain area, a certain panel on your
screen? You use the Ajax Refresh statement. You can not only
select which is the target widget that you want to refresh, but optionally select
an animation, so that the user has a visual cue that something has changed.
It's important to stress that to point the Ajax Refresh to a widget, this widget needs to
have a name so it appears in the drop-down. All the big widgets like table
records or list records, they all by default have a name, but for minor widgets
you might need to go into the screen and explicitly name that widget so you can
then call an Ajax Refresh on it. You can have multiple Ajax refreshes in the same
call and they will be executed from top to bottom so you can for example decide
that you want to update the footer of your page and the top right-hand corner of your
page, and this means that you will be calling the Ajax Refresh statement
twice passing in a different part of your page. As mentioned there isn't any
implicit content being sent to the user, you will need to specify which ones you want
and only those HTML contents will be refreshed on the page.
Incidentally if the screen action that you're executing hasn't been called
via a Ajax submit but rather via the normal submit these statements will
just be ignored. Now refreshing a widget might not be enough. If the underlying
data that feeds the widget hasn't been changed
you might not see anything happening and because of this that's why you have the
Refresh Data statement. This will re-execute, you can call it to re-execute, an
aggregate that you have defined in the Preparation of the current screen and
then you normally couple this with the Ajax Refresh statement afterwards.
So as you can see here on the right hand of the slide, we have the properties of
the GetMovies aggregate that is being run in the Preparation
and we have the screen action that is calling the Refresh GetMovies thus
re-running the GetMovies query in the screen action followed by the refresh,
the Ajax Refresh, of the MovieTable widget, which will send back the whole table to
the user. In case you want to refresh just one particular row of your MovieTable
for example, you can do so: you need to specify the second property, set the
row number, and then the Ajax response will only send the payload to the HTML for
that one row rather than of the whole table record. And since we're talking about
selective refreshment of a row or specific rows of your table records
or list records, it's worth noting that the system actions ListAppend, ListInsert,
and ListRemove which are of general use in any list, when they are
called on a list of one of the table record or a list record (and you're
within an Ajax request context), this will also trigger the equivalent operation in
the screen side of things. So the ListAppend will insert something at the
end of your table records, the ListInsert will insert something at a
certain position in your table records on the screen and the ListRemove will
make disappear one particular row of your table records. Now the kind of
interaction that the user has with the widget that can optionally trigger an
Ajax behavior changes according to the widget type. So as we have mentioned
the most obvious one is when you click a link or a button but you can also interact
with a container, and on clicking a container trigger an Ajax request. As for
input widgets such as the input and input password, checkbox, radios, combos, etc,
the operation that can optionally trigger an Ajax request is not a click
but the change of a
value, so you can trigger an Ajax request every time a user types something into an
input or clicks a radio button. And that's it for Screen Lifecycle and the
Ajax Interaction. The key takeaway to note is: don't forget, if the screen
action is being run by Ajax, the End node means the end of the request. If you want
anything to be refreshed on the screen you need to explicitly call an Ajax
refresh on it and if you need the data, you need the list that seeds the widget
to be changed,
don't forget to refresh data before calling Ajax Refresh. See you in the next
lesson.