Search

User Manual

Getting Started


Modules and Platform


Appendix


Tutorials & Helpful Tricks


Glossary


Strategic Partner Links

Sepasoft - MES Modules
Cirrus Link - MQTT Modules

Resources

Inductive University
Ignition Demo Project
Knowledge Base Articles
Forum
IA Support
SDK Documentation
SDK Examples

All Manual Versions

Ignition 8
Ignition 7.9
Ignition 7.8

Deprecated Pages

Skip to end of metadata
Go to start of metadata


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.

Root Views vs Embedded Views

Root View is an instance of a view that is mounted in a Page as a primary, docked, or popup view. This means the view acts as if it were a separate window.

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.

During design-time, views need not be specified as root level or embedded. Views can be used as either a Root View, an Embedded View, or both. It is possible that a single view may end up being instantiated as both a root level 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.

View Properties

Views, like components, have properties. They are organized into a few types: propsparams, 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: ColumnCoordinateTabBreakpoint, 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. 


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

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


Containers and Layouts

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 container called root that cannot be removed or renamed. The dimensions of this container will span the entirety of the view.

In Perspective containers serve an additional purpose - they indicate what layout strategy should be used 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.

Keep in mind that containers are also components. Each container type has its own properties and is configured independently of other components and containers that are in the parent view.

Layouts

Every view and container in Perspective has an associated layout, which is, simply put, a way of defining and describing the way that elements inside the container interact. Layouts are set when views and containers are created, and cannot be changed. If you wish to change the layout of a view or container, you'll need to create another one. There are five layouts used in Perspective:

Layout TypeDescription
CoordinateThis is the most simple layout. Components inside this layout 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.
ColumnThe Column layout 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.
TabThe Tab layout 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.
BreakpointThe Breakpoint layout 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.
FlexThe Flex layout 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.

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 layouts 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 allow 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

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.

Embedded Views

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.

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.


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. You'll notice that when you enter a name, the Page URL will also be entered at the same time, unless it is your very first view in your project, then the page will be mounted to the Page URL "/" or "root" as shown in the image below.  
    2. Select a Layout type. Choose one of the layouts described above.
    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.



      When creating additional views, the Page URL will automatically get filled out for you as you enter the name of your view. If you use a space in your view name, the Page URL will replace the space with a hypen 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.


Test Your Responsive Design using Chrome's Developer Tools

When designing for mobile-responsive applications, designs must work everywhere, on any device from a smartphone to a desktop with full-sized monitors, in a optimized format using one design. Websites not only have to look great on many different screen sizes, but they are also expected to perform well. You can test your responsive designs using Chrome's Developer Tools by integrating an emulation feature called Device Mode. Device Mode can emulate a mobile device environment to test a website's responsiveness in different devices. It can also change the resolution of your page to reflect the size of screens from different manufacturer's devices.

Any modern version of Chrome will work. You can access Chrome's Developer Tools from a Perspective Session by opening Chrome's menu > More Tools > Developer Tools or by clicking F12. A toolbar will open at the top of the Perspective Session page below the URL you are viewing. A panel is displayed on the right side of the page showing the HTML for the current URL. From the toolbar, you can select a specific mobile device and size as well as show the actual device frame by clicking the Device Mode icon (). Chrome will emulate different devices with viewport sizes, and other features.


To activate Device Mode, simply click the Device Mode icon () at the top of the Developer Tools window. You can use the Device Mode icon () to toggle between devices. You can hover lines of code and Chrome will highlight the specific element on the screen.


In the Perspective Session, you can also use the handles in the Chrome browser to grow and shrink the screen size. There are a host of developer's tools, so it's a good idea to take time to familiarize yourself with Chrome's Developer Tools. It has potential to save you hours of work and help you to make your application site friendly to the increasing variety of devices people will use to access your application.



Related Topics ...
In This Section ...

 

  • No labels