Hello and welcome to the first lesson on widgets in the OutSystems platform.
A widget is an element of the graphical user interface, that displays information or
provides a specific way for a user to interact with an application and you
normally have specific widgets, to capture or display information data of
specific types. In this lesson we will cover some of the basic widgets that the
OutSystems platform provides for you.
These are the most common widgets you will see in every screen, in every
application done with OutSystems. First, we will show you some basic display
widgets, those that just convey text to the user, then we'll talk a little bit
about inputs and finally look into some of the most basic navigation and
interaction widgets. To use a widget in your module, you'll have to open the screen
editor and on the left-hand side you will have the toolbox displaying the
available widgets. Simply drag and drop the widget you want to use into the screen
canvas and it will be available for you. The first widget, is the expression
widget which is used to display calculated values in the screen. If you
specify an example
this will show up in the preview while you're editing your module. There's an
interesting property that this widget has, which is the escape content: if you
set it to yes it will allow you to inject HTML into the page. In the
interest of security the default value for this property is No. The free text
that you type into your screen is also wrapped by a text widget, this allows you to
then, for example, apply styling into the text. The simplest widget, to gather
information from the user, is the input widget, allowing him to type in any
information. Every single input is actually bound to a variable that will
hold whatever it is that is typed into, by the user. You can specify what type of
input data we expect on this widget and it's worth noting that the look, the
visual look of an input
might change depending on the data that is associated with it. If you want
to force the user to provide some information into this input before
submitting the form that it's part of, you need to set it as mandatory. If you
specify a null value in a non-mandatory property, if the user leaves it blank,
this will be the value that's assigned to the bound variable. Finally, you can
specify the prompt property
this will give the user a hint of what you expect to be typed in, to this input.
Now, that we mentioned input widgets we can go back and talk about the third
basic display widget which is the label. Much like in an expression you can
specify the value to be displayed and an example for preview purposes. Where it
differs from any expression, is that you can specify an input widget on the
current screen that will be bound to this label. This means that, if the input
is mandatory the label will have a visual cue indicating so. Likewise, in the
interest of accessibility, if you click on the label, the caret, the focus, will
move to the associated input. The final set of basic widgets is the button and
the link, that will allow the user to trigger an action or navigate to a
different screen. These widgets always require a destination, which is either the
screen action that has the code that will be executed or a target screen to
navigate to. The method of actually submitting or navigating is specified
by the "Method" and this will be covered in a later lesson.
It is possible to specify a confirmation message
this will make a Pop-Up show up before the link or button is actually followed.
Mechanically speaking, buttons and links work much the same way but since the
link is actually more flexible in terms of what it can contain, it might be
preferable to use in modern applications because, for example, you can inject an
icon into it. Now that we talked about the building blocks, the most basic of
widgets, let's look into how this can be grouped together to convey
more complex information or to grab compound information from the user. We'll
talk about a couple of layout widgets: the container and the table, and a couple
of record widgets: the form and the table records. The first layout widget, is the
container, which allows you to group widgets and then apply a style or
apply a behavior into the combination of these widgets. It is nothing more than a
box that can contain other widgets and you can specify its width, although
its height is normally based on the contents therein. It also allows you to
specify a certain style and a certain position of that cluster of widgets
that's inside of the container. One of the practical uses of this is for
example hiding the whole group of widgets that are inside via the display
property, A container underneath is nothing more than a div element, if you
know the HTML element. Another structural widget, is the table widget, that displays
the contents in a table kind of way. You can specify upon creating the number of
columns and rows that you want for your table, after the table is created, you
can dynamically, in the editor, create new columns, remove columns, same thing about
rows and move them about, using the toolbar. It goes without saying that the
cells of a table can contain other widgets and although you can specify
dimensions, by the nature of the HTML table cells, the height and width will
actually respect the contents of it. Because of this sometimes odd behavior
the tables are falling out of favor in modern development, so you don't see them
around too much anymore.
Let's look now into a couple record widgets and they're called so, because
unlike the base widgets, that we saw before, they operate over a record or
list of records depending on the type of the record widget. What they do have
in common in terms of operation is that they are bound to this compound variable
and their children, the base widgets that are contained inside, in turn bind to
particular fields or particular attributes on the data property of the
record widget. So, in a sense the record widget works as a sort of proxy or a
wrapper for all the children widgets inside, delegating the variable that it
is bound to it into those child widgets. Let's start with the form widget. The
form widget allows you to show and especially, edit a single record. It can
contain input widgets inside and provides a local property to hold this
input data.
Furthermore, it has a source record, that defines what is the data type of this
local property and also is used to fill in the local property with the
initial values. Inputs inside, bind to the form's local property and when you submit
they are validated together. One thing important to note, is that it can contain
not just input widgets but any other kind of widgets, so really, inside the form you
don't really have any layout constraints. So you can add, for example, containers
inputs, labels, etc., etc., and in fact, if you use the drag-and-drop accelerator to
drag attributes and build up your form you'll see that actually, it's created for
you, a container with a label and an input for attributes. While the form
widget deals with one single record, for display or editing, you have the table
records which displays multiple records in a kind of a tabular format. Much like
the form, it also provides a local property to hold data and you specify a
source record list, that defines the type of this local property and also
initializes the local property list with a copy of your source record list, so in
a sense it's very, very similar in terms of binding mechanics with the form. Once
you're actually rendering, once you're actually building the screen, using a
table records, the table records iterates through the local property list
displaying one row, one record, per line on the local property list. Much like in the
table widget, each cell of a table records, can contain other widgets and
similarly, you can use the table toolbar also for table records to move and add
and remove columns. If you use the drag-and-drop accelerator to build up
your table records, by default it will create one column per each attribute,
entity attribute, that you dragged into the records. However note that you're not
forced to leave it like this, to leave this layout, you can change it afterwards
for example, you can opt to move the zipcode expression, that was built by the
accelerator, underneath the street and have a different layout.
Ok, so you have the same flexibility as you also had in the form, please note
again, since the table records is based on top of an HTML table, the cell
content's dimensions will stretch to hold whatever contents are inside. And that's
basically it for the first batch of OutSystems widgets. See you guys in the next
lesson!