Developing Business Logic
Widgets II
This lesson is part of the Developing OutSystems Web Applications course.
LEARN MORE

Transcript
Hello and welcome to the second lesson on widgets in the OutSystems platform. If
you haven't gone through the first lesson, please do so before proceeding.
So, on this lesson, we will cover a few more base widgets that you get
with OutSystems platform out-of-the-box. First, we will talk about the if widget, then
we will move to other input widgets, that provide choice, like checkboxes, radio
buttons and combo boxes and finally, we go back to the record widgets, to tell
you a little bit more about the third record widget, which is the list records.
The if widget allows you to display one of two sections in your screen, these areas
of the screen can have any widgets that you desire
although, in this particular example, on the right-hand side of the slide, we just
have a couple of expressions. It selects which of the areas to display, via
boolean condition, that is evaluated during the build-up of the screen. Inside
service studio, during development, you can actually visualize one branch, the other
branch or both branches by selecting one of the three bullets to the right of
this widget. Now, the check box allows for selecting a yes-or-no kind of answer, a
binary kind of answer. It is bound to a variable, that will hold the data and by
definition this variable needs to be a boolean. Moving on to the radio button
this widget allows the selection of one out of many alternatives. Now, each radio
button provides one option, one single option and effectively, you will need
several radio buttons working together to provide the several options. Every
radio button needs to be bound to a variable, that will hold the data and it
is this variable that will dictate how the several radios, in your screen, work
together. The value, associated with the radio button, is written to the variable
that it is associated to. So, if in your page, you have four radio button widgets, two of
them bound to a variable, say called Gender
and two bound to a variable, say called Subscription type, the first two will be
alternates to selecting male or female
while the other two will be alternatives to, for example, selecting a daily or
weekly email subscription. It is the variable therefore, that they're bound to,
that dictates how the several radio buttons cluster together. The combo box
is also a choice input widget.
It also allows you to select one out of many alternatives and it has several
modes of working, which we'll explain in the next few slides. The look of a combo box
is a drop down, with the selection of the values, unlike the radio button that we
spoke previously. The first mode of operation, is just showing all of the
records in an entity or a static entity and you can do this by setting the
source entity and selecting an entity or a static entity. You also have the source
attribute, that dictates what is displayed in the combo box. Setting this
attribute is optional, in case the selected entity or static entity has got
a label, then it defaults to displaying the label. It is also bound to a variable
that will hold the identifier, and this is the important thing, it will not hold
the text of what was selected but rather the identifier of the record that
was selected. An alternative to selecting all of the records of an entity or a
static entity, is to specify a custom record list, say for example, the output
of a query, as we see in this slide, if you take this option it is impossible
for the platform to immediately know which attribute you want to display
because this source record list might be anything, so this means that you need
to specify what is the source attribute, which of the columns, that is in the list
that is the source of this widget, that you want to display to the user. If the
attribute that you've selected is not of an entity but rather a computed
attribute, the platform cannot infer, what is the ID that you want in the
variable, when someone selects this custom column.
Therefore, if you select a computed attribute, you'll also need to specify a
source identifier attribute. Despite this difference, the actual operation then is
very much the same, the value that you select will have an associated
identifier, that ends up in the variable bound to this widget. There is a third mode
of operation whereby you specify explicitly, which values you want to
appear in the combo, as you can see here, every special list entry has got a value
and an option.
The way this works in runtime is: the option will be the text that's displayed
in the combo box and the value, the same value with the same number, is the one
that will be written to the special variable. Notice that when you're using
the special list, your selection doesn't go to the "Variable", as is the case on the
previous two modes of operation that deal with entities, but rather into the
"Special Variable". So, in this particular case, if you were to select the option
"All", then 42 will end up in the special variable. It's worth noting, that if you
pre-fill in, the variable that's the special variable for this combo, with one
of the values that is in your special list, this will be the option pre-selected in
the combo box on-screen. In closing, it's important to refer that you can actually
mix these two modes together, so you can mix having options that are sourced from
an entity, static entity or query together with special list options, in the
case that the regular source and the special lists are used simultaneously, then
when you select an option from the special list, the bound "Variable", will be set to
NullIdentifier(). Don't forget, the "Variable" is the one that catches selections from
the regular source mode.
Likewise, when you select a regular source option, the "Special Variable" will
be set to the null value of its type, so it could be there 0 or an
empty string, depending on what you selected for special variable. With the
proper code on the screen action, after submit, you will be able to decide if the
user has selected one option from the regular source or one option from the
special list source and act accordingly. In closing, let's talk about another
record widget, which is the list records, that also displays multiple records but,
unlike the table records, it does so in the freeform layout.
It also provides a local property to hold the data, like the table records, and
this local property feeds off the source record list, so the source record list
defines the local property data type and also sources the initial values for the
local property. During screen rendering, the platform iterates through the local
property list
displaying an instance, of the freeform content for each record, in the list
property.
The big difference to the table records, is the use of a line separator, that you
can specify to be a new line, a bullet or nothing at all. Because of the freeform nature
of this particular widget, it will allow you to do things like a
comma-separated display of several expressions, something that the tabular
form of the table records wouldn't be helpful to do. The key takeaway then is:
if you want a tabular output as you iterate through the list, use the table
records, if you want the freedom to lay out each row content as you see fit
then go for a list records. And that's basically it for widgets two. See you guys
in the next lesson!