You're currently browsing the Ignition 8.0 docs. Click here to view the latest docs.


Views and Containers are an integral part of the Perspective design experience because they work together to create your HMI screens - the windows into your application. The view is the primary unit of design and the Container provides a way of laying out and organizing child components within a View. Let's see how views and containers work.

Views

Perspective Views are unique in that they can act as both a top level screen (taking up a whole page in your session) or a component (embedded in another view). Each view is a project resource, which are named and organized into folders in the Ignition Designer’s Project Browser tree. These folders/paths are important not only for organization and referencing, but also because these paths uniquely identify each view, and are used in the session (runtime) for navigation. Each view has a Container type that decides how the components inside it will behave.

While views themselves are not strictly components, there are components that can display an instance of a View, such as nesting views inside of other views. There are also repeater components that may dynamically create view instances at runtime.

Views can be mounted in a Page as a primary, docked, or popup views. For more information on how pages work, see Pages in Perspective.

Embedded Views

An Embedded View is an instance of a view that is used as a component within another view. Similar to how containers can be added inside another container. An embedded view in Perspective is actually created using the  Embedded View component , which internally opens the view. You'll notice when you nest a view inside another that the Embedded View component has some properties that are distinct from those of the view you're nesting:

  • path is the path to the view you wish to embed.

  • params is an object in which you'll put any parameters you wish to pass through to the embedded view

  • useDefaultViewWidth and useDefaultViewHeight are two very critical properties when nesting a view. They control whether a view's default configured dimensions are carried into the embedded view (using scrollbars if the defaults are too large for the embedded setting), or whether the view is scaled from its defaults to match its new setting. Typically if you're finding unwanted scrollbars, unchecking these properties often achieves the desired result.

When designing your project, views need  not  be specified as embedded. It is possible that a single view may end up being instantiated as a regular view and an embedded view, even simultaneously in the same session. For example, you may have a view that shows 10 tanks using a view repeater as well as a popup that shows the details for just tank 1. This is common when the properties of a view are used to pass in parameters.

For complete description of each of the view properties, see Perspective - View Object. To access the properties for a view, select the view in the Project Browser, for example:


The property types will be displayed in the Perspective Property Editor. 


Root level containers have properties are unique to the container type. For more information, see  Root Container Properties .

On this page ...

IULocgo


Anatomy of a View

IULocgo


Docked Views in Perspective

View Properties

Views, like components, have properties. They are organized into a few types:  props params , and  custom . Custom properties can be defined for views. They act just like custom properties of a component and are internal to the View, and can be referenced by all child components and containers in that view. 

Each view contains exactly one “root” level container, which may be any of the available container types:  Column Coordinate Tab Breakpoint , or  Flex . Therefore, the design experience of a View is simply the design of the selected container type. 

The view properties have three categories:

  • Props - Properties used to configure the component's visual appearance, behavior, and data.
  • Custom - Properties defined by the user. They have no direct effect on the component, but are used as variables for the application designer's convenience.
  • Params - Properties only found on views. They define the parameters that may be passed in or out of that view. 

For complete description of each of the view properties, see Perspective - View Object. To access the properties for a view, select the view in the Project Browser, for example:


The property types will be displayed in the Perspective Property Editor. 

Input/Output Parameters

The properties inside of the  params  collection define parameters for the view. This is how views interchange information with other entities, such as a parent view or the Page. Parameters must be defined as "input", "output" or "in/out". The default direction will be "input".

  • An  input  parameter is not bindable from within the configuration of a view. The purpose of an input parameter is to receive information from an external entity. For example, when a view is opened, it may receive parameter values which will become the values of its input parameters. Or, if a view is placed inside another container, that  instance  of the view will show the input properties, and they will be bindable.
  • An  output  parameter is the opposite. These parameters are bindable from within the configuration of the view. If an instance of that view is then placed inside another container, the output values will appear as properties, but not be bindable; they will be read-only from the outside.
  • An  in/out  parameter combines the features of both input and output. An in/out parameter is bindable from both inside the definition of a view, and from the outside. This can be useful when making a view that acts as a decorator around an input, for example. Suppose you had a view that contained a Text Field component and an Image component, and the image displayed whether or not the text in the Text Field meets some criteria. You would use an in/out parameter to mirror the text across the view boundary.



Popup Views

Popup Views float on top of a primary view and docked views. They are not part of a page’s initial configuration, but may be opened using a popup action or scripting call. An easy way to create a popup view is by using a Button component to open and close the popup view in the primary view. A popup view can be opened and closed at the user's discretion in a Session. To learn more, go to  Popup Views .

IULocgo


Popup Views


Configuring Views

Views can be configured in many different ways. They can be displayed as the entire browser window if it is configured to be the primary view of a page. Views can also be displayed across the top, bottom, or sides of the browser window if it is configured to be a docked view.   A view can also be displayed floating on top of the page as a popup view.  A view can also be embedded within another view in various ways using a variety of components that are able to display embedded views.  Pages in Perspective talks more about page layout and how views are configured on a page.

When you start designing your project in Perspective, the first thing you'll do is create a view and how you want to configure it. You can configure it as a primary view attached to a Page URL, or as a docked view on a specific Page URL with a primary view, or you can choose your docked view to be shared across all pages in your project. You also have the option of creating folders for your views or simply leaving all your views in the Views folder.

  1. In the Project Browser, right click on the Views folder and select New View.
    1. In the New View window, give your view a name. 
    2. Select a root container type.
    3. Make sure to check the Page URL checkbox if you want your view attached to the Page URL. Perspective will match the Page URL  with the View's folder structure upon creation.
    4. Click Create View.

      In release 8.0.8 the New View screen was updated to clarify the selection of container types.


      When creating additional views, the Page URL will automatically get filled out for you if the Page URL option is checked. If you use a space in your view name, the Page URL will replace the space with a hyphen as shown in the image below.  

  2. Once you create your view, the view will open in the Designer workspace, and you can begin adding and configuring components. 




  3. If you want to add additional containers, simply select another container type and drag it to your workspace. The container type added in this example is a Flex container. 

    To add components to this container, double click on the container to deep select it. Then you can drag components into the container. Notice that the properties are now in the Flex container. 




Once you create your view, the next step is to set up your navigation using Pages.


Containers

The Container is a special kind of component. True to its namesake, a container is a component that contains other components. Within every created view is a  root container that cannot be removed or renamed. The dimensions of this container will span the entirety of the view. If you wish to change the container type for a view, you'll need to create a new view. In the Project Browser, next to the root there will be an icon representing the type of container it is.  There are types used in Perspective:

In Perspective containers enable you to have a layout strategy to control the size and shape of any housed components. The layout strategy defines how the container displays each of its child components in the view. There are a variety of container types that support different layout strategies.

Root Container Type

Icon

Description

Coordinate

This is the most simple container type. Components inside this type use basic X, Y, Width, and Height position properties. They can be fixed in size, or be configured to grow and shrink proportionally when the view is stretched.  To see the properties and scripting functions available, got to Perspective - Coordinate Container and  Coordinate Containers.
Column

The Column type shows a column-based layout and has three breakpoints. Breakpoints help manage a view when the devices using your session are very different sizes. Components inside this container type can span one or more columns, and you can add as many rows as you want. Row heights are determined by the tallest component in that row. To see the properties and scripting functions available, got to Perspective - Column Container and  Column Containers.
Tab

The Tab type is used to show multiple views in the same page, while cycling through them all by clicking on each tab. You can add a single component, container, or view to each tab space. Each child element uses a tabIndex property for its position. To see the properties and scripting functions available, got to Perspective - Coordinate Container and Tab Containers.
Breakpoint

A Breakpoint container type allows you to create multiple versions of a single container using a pixel width as the cutoff. This allows you to completely change the look or structure for displays on mobile versus desktop sessions. To see the properties and scripting functions available, got to Perspective - Breakpoint Container and Breakpoint Containers.
Flex

The Flex type shows a single row of components spanning the height of the container. It allows you to set each component to either stretch to fill the available width, or to use a static width. The components in this view type will reposition and realign based on the size of the view. To see the properties and scripting functions available, got to Perspective - Flex Container and Flex Containers.

Breakpoints

A simple strategy to accommodate radically different screen sizes is to design a view or container in several different ways, with each design tailored to different screen sizes. The column and breakpoint types accommodate this design strategy, by picking one of two or three different containers to open based on a specific range of pixel widths for the session. The term "Breakpoint" is a common piece of terminology used to describe this design - it is the width in pixels at which the Perspective session decides to use one container over another.

Using Column Containers

The Column container is a good option when you want to have the same components and views for every screen size, and simply want to lay them out differently at smaller or larger sizes. 

Selecting one of the sizes will give you the opportunity to configure components' layouts for that size. For instance, selecting Small will allow you to position the components, embedded views, and containers in your view in a way that makes sense for mobile devices, since most mobile phones will sport a session width less than 480 pixels. Rearranging the same components in the Medium container would provide a nice design for larger smartphones, many tablets, and some desktops, while the Large configuration will yield a container that works for high-resolution monitors and televisions.

Using Breakpoint Containers

The Column container is an easy-to-use option for simple layouts, but more involved ones might require more customization. Perhaps you want desktop, tablet, and mobile sessions to look and feel quite different, or you want to use one of Perspective's new navigation components, but only for mobile devices. Even in these circumstances, you don't have to design several sets of pages, or even several projects, to all implement the same task.

Breakpoint containers enable you to design views tuned to different screen widths, but unlike a column container, where a single view can take on three forms, in a breakpoint container you actually specify two distinct views, each with their own components and functionality. Breakpoint containers are thus the more flexible option; as long as your "mobile" views share an essentially similar framework with your "larger" views, you will be able to develop the views concurrently, and the Perspective session will decide at runtime which set of views to use. You can think of a breakpoint container as bundling together two views that serve a similar purpose, but are tailored to different screen sizes.

Nesting Layouts Using Containers

Sometimes you may want to compartmentalize a view or container in a particular way, either to modify the component layout or organize the structure of your components in the Project Browser. Containers are a special kind of component that can contain children and can also be nested, which supports multiple layout strategies. This means that application designers can nest containers inside of other containers to compose layout strategies that are more complex and capable than any one container can provide.

You might want to have nested containers to create a more complex layout. For example, you could have a Tab container that has several tabs with very different information in each tab. In one tab, you might have a table that looks great on a desktop but terrible on a phone. Using a Breakpoint container inside of only one tab in a Tab container will allow you to make a more useful mobile experience while still showing a table on a desktop computer.

Single-Component Containers

Sometimes you'll want to make a very simple view for use inside a higher-level setting, like a Carousel or a Breakpoint container. If you only need a view to hold a single component that fills the container, you can:

  • Use a coordinate container in percent mode, and give the component X and Y of 0, and width and height of 1.
  • Use a flex container, giving the component a basis of 100% or auto.

Repeated Containers

Sometimes you'll need to repeat the same container a specific number of times in a row or column, or you want to create a grid of child containers. For this purpose, you can:

  • Use a Flex Repeater component, in the specific instance that you only need a row of instances of a specific view.
  • Use a Flex Repeater component, when you want to use more than one container or view.



  • No labels