UI Interaction Basics
Screen Lifecycle: Interaction
This lesson is part of the Developing OutSystems Web Applications course.

Hello and welcome to the second screen lifecycle lesson, where we will build
with interaction. If you haven't gone through the first lesson covering the
layer paradigm and normal rendering in OutSystems, please do so before proceeding.
So, how do users interact with your web applications done in the OutSystems
platform? They start by following the link, that will render the screen that
they will interact with, and this is covered on the first lesson, then they fill in any
of the inputs and press a button to submit the result to the server. The act
of following links is associated with the concept of navigating, likewise the
concept of pressing buttons, is normally and historically been associated with the
act of actually submitting user input. It's worth noting that, while in the past
the link HTML widget was strongly associated with the act of navigating
and the button HTML widget was strongly associated with the act of submitting
user input, in this day and age, the two widgets are actually interchangeable. It's
worth noting though, that regardless of which method we're talking about,
navigation or submit, a new request will be sent to the server, which will in turn
send us a new response. Let's start by discussing the navigate method. This is a
strictly client-side way of interacting with the page. When you click a link or a
button that is of type navigate, your browser will immediately request a URL
that is different from the current screen. The destination of a link or
button with the method navigate can be either a screen or any URL on the
internet. Navigating to a destination
uses the HTTP GET method
which means that any parameter to the target URL or screen, is sent in the URL
itself, in the query string. Any of the inputs that you may have filled in on
the current screen will be ignored and not submitted to the server and your
browser will actually show the URL of the target that you're pointing to.
In summary, when you do a navigate, your actually intending on starting a brand
new set of interactions in the target, in the destination of this navigate. The
submit method, is different, it carries with it the intention of interacting
with the server and having code run, in the server, in response to this
interaction. You can choose, as the destination of a button or link with the
method submit to be: a screen action of the current screen, a target screen, or
an external URL. By far the most common case is for the destination to be a
screen action of the current screen, where you will have code that will
handle - will process - the inputs that the user has submitted and maybe write any
outputs to the database. Submitting to a screen, uses the HTTP POST method for
this means that the input fields, as well as any parameters, are sent in the body
of the request to the server and therefore, what you type into the screen
will actually be taken into account in the execution of the screen action. The
browser will show the URL of the current screen and when you actually complete
processing the data that was sent, at the end of the screen action, you can
actually use server-side navigation to move to a different screen. As mentioned
the most common destination for a submit is a screen action. A screen action can
contain code for any purpose but it normally focuses on logic, that directly
deals with the input sent from the screen.
This includes things like validating what was submitted
processing and storing the results in the database.
Don't worry because we will cover validation in more detail in a later
lesson. Screen action has in scope all the form inputs submitted to the server
all the input parameters, both of the screen and of itself, all the local
variables, both of the screen and of itself, and you can even access outputs
from the preparation
although this is highly inadvisable due to performance considerations. Now, at the
end of all the code that is written in the screen action, the flow needs to
finish - needs to end - with one of two nodes: it can finish in an end node or in
a destination node. The end node is the most interesting one, because it carries
with it the intention of staying on the same screen, what happens is that the
server will cycle back to the preparation, re-execute that, rebuild the
screen and resend it for rendering completely to the user.
It's worth noting, that the cycle back, via the end node, will preserve the values of
all the variables and all of the inputs in the current screen, allowing you to
seamlessly simulate continuous interaction with the same screen. You can
also end the screen action using a destination node, this carries the
intention of actually jumping, moving to a different context. The target of a
destination node can either be, a screen on your application or an external URL
to your application. Depending on the type of the target you actually get a
different icon for this destination node, as can be seen on the right hand side of
the slide. It's worth stressing here the difference between finishing a screen
action with an end node and finishing a screen action with a destination, that
is the current screen. Although at first glance this might look like the same
thing, it actually behaves differently. If you use a
destination node to the current screen, you're actually going to be resetting
all of the context of the current screen
this means that all variables will revert to their default values, unlike
the end node, that preserves the variables, as we explained previously. And
this is it for screen lifecycle interaction. It's worth noting that we've
talked about navigation and we talked about the "common" type of submit. Ajax-
type submits will actually be handled in a later lesson.
See you later!