Working with User Input Elements

Working with User Input Elements

Logi Info
v12.6 - Oct 2018

Page 1

1 | 2

User Input elements allow users to interact with applications, most often to provide reporting criteria. This document discusses a variety techniques for working with these elements. Topics in this document include:

 

When Are Input Values Available?

Logi reports use the basic HTML FORM-submission mechanism for posting input control values. This means that a page has to be submitted before any of the values in its Input elements will be available for use in the next or reloaded page. Attempts to access @Data tokens for those values in the page before it's submitted will not work.

A common technique is to display a page, let the user enter values and submit the page, and then re-display the same page with dynamic content displayed based on the input values.

Another common technique is to display a page, let the user enter values and submit the page, run a Process task that does something with the entered values, and then re-display the original page.

Some script-based techniques can be used to initiate local actions on the input values, without submitting the page. For example, if text is entered in an input control, it can be capitalized when the mouse leaves the control.

  Back to the top

 

Working with Change Flags

You may find it useful to know, after a page with User Input elements has been submitted, whether or not any changes were made to their default values - did the user make any changes? This, for example, might let your code decide whether or not to take some action, such as updating a database record. Logi Info provides a "change flag" mechanism to let you make this determination.

A "change flag" is simply a Request variable with a True or False value; an Input Hidden element is added to a Report definition to generate that value. Other User Input elements specify the Input Hidden element's ID in their Change Flag Element ID attributes. When the page is submitted, in the next Report definition or Process task, the request variable associated with the Input Hidden element will have a value of True if any changes to Input elements occurred.

This change flag functionality relies on the DHTML "onChange" event supported by all browser. Prior to Logi Info v12.1, this event was used to the exclusion of other events, so you could not also use your own onChange event handler with elements implementing a Change Flag Element ID.

Support for multiple events is now available. When using a change flag, you may also add Event Handlers to User Input elements and they will be processed after the onChange events associated with setting the Input element change flags.

  Back to the top

 

Aligning Input Elements

One challenge when working with Logi Studio is to get user input elements neatly aligned. The Input Grid element has been provided to assist you in doing this.

The Input Grid is not an actual Input element but is instead a container for Input elements that lets you align them. It can be thought of as a two-column table with the first column containing the caption describing an Input element and the second column containing the Input element itself. Adding multiple rows allows a data input form to be created. The overall width of the table and the width of the caption column can be set using attributes.

 

In the example shown above, user input elements are placed in a report definition without using the Input Grid element. As you can see, the alignment of the elements on the page is poor and the captions are not vertically centered on the controls.

 

In the second example, above, the user input elements have been made the children of an Input Grid element and the resulting, more precise, layout on the page is evident. For the purpose of this example, the Input Grid element was assigned a style class that colored its background, so you can see it more clearly. Attribute settings have made the entire grid 300 pixels wide and the caption space 120 pixels wide. Note that, in this definition, New Line elements between the input elements are no longer necessary.

 

There are some limitations, however. No other elements, such as Buttons or Labels, for example, can be placed within the Input Grid. These elements need to be carefully placed outside the grid, in their own HTML table using Rows, Row, and Column Cell elements, as shown above, if similar alignment is desired. Once again, for clarity in the example, this table has been assigned a style class to give it a colored background. 

 

There are also times when you may wish to have the caption follow the control, rather than precede it. This can't be done within the Input Grid. Instead, as shown above, another row has been added to the table below the Input Grid and an Input Checkbox element placed in it. The Input Checkbox's Caption attribute has been left blank and a separate Label element provides the "caption" following the checkbox.

The Input Grid and HTML tables are useful elements for alignment. We've seen how you can combine them and there are a variety of combinations that can work. For example, if you create a one-row, two-column table first and then put an Input Grid into each column, you can even make a two column (or more) data entry form.
 

Alignment Using Style Classes

The user input elements typically have two attributes related to style sheet classes: one for the entire element and one for the caption. This allows, for instance in an Input Select List, the font for the caption and the list items to be set to a certain font and size and the caption only to be set to bold.

 


     

It also allows other style selectors, such as padding, to be applied to the caption to align it correctly. For example, in the horizontal arrangement of radiobuttons shown above, padding-right: 3px can be applied to the Caption to increase the space between each caption and the next button.
 

      

The default alignment for the caption of a Input Text Area element is centered vertically, as shown above left. This may not look very good in a stack of input elements, so the vertical-align: top; style selector can be applied to position the caption at the top of the input box.

These are just a few examples of the many things that can be done using style classes. Be sure to distinguish between situations where style classes need to be applied to the elements themselves and to the objects that contain the elements, such as an Input Grid or HTML Table.

  Back to the top

 

Using AutoComplete

The AutoComplete element can be used to provide users with data-driven assistance when using Input Text and Input Email elements.
 

As shown above, the AutoComplete element is added as a child of the Input element and has its own child datalayer; all datalayer types are supported.
 

When the user begins typing into the Input element, a drop-down list of values, shown above, will appear. The list will consist of values from the datalayer column identified in the Column Name attribute. Items in the list will be progressively filtered with each letter typed. The user can select an item in the list at any time.

When the AutoComplete element's Multiple Selections attributes is set to True, the user may enter or select multiple text items, which will appear in the Input element separated by commas. Items that have already been added to the Input will be automatically filtered out of the remaining choices.

The default separator character for multiple selections is a comma. You may change this to another character by manually editing the element's XML source code, in Logi Studio's Source tab, to include an InputValueDelimited attribute and value. For example, this will set the delimiter to a semi-colon:

The resulting @Request variable created when the page is submitted will contain an individual value, or if multiple items have been entered/selected, a comma-separated list of values. Trailing commas will be removed automatically. See the Input Select List > Getting Its Data section for information about parsing comma-separated lists for SQL queries.

The AutoComplete element includes a Tooltip Column attribute. Enter the name of a data column here to display a unique tooltip value for each data item.

  Back to the top

 

Wrapping in a Fieldset Box

The Fieldset Box element provides a visual container for other elements, including User Input elements.
 

The example above shows a Fieldset Box, with a caption of "My User Input Controls" surrounding Input Select List and Input Radio Buttons elements. The box has been styled to have a pale blue background.
 

The elements used to produce the previous example are shown above, and this style sheet code:
 

#myFSBox {
    background-color: AliceBlue;
}

#myFSBox legend {
    padding: 0px 5px 0px 5px;
}


was used to style it. The second class sets the space before and after the box caption text.

  Back to the top

 

Inclusion in Data Tables

Some applications display data in a Data Table and include user input elements in each row of the table. A common example is a "Delete" checkbox for every record.
 


     

This can be done in Logi applications, but generally requires use of a Process Task to process the input values. DevNet offers a sample application that shows you the coding techniques for doing this.

In addition, this technique is not recommended when hierarchical data is being used. The complex data relationships involved make it impossible to uniquely identify the associated user input elements. This prohibition applies to obvious hierarchical representations, such as the Data Table, and also to elements like the Data Tree, which use hierarchical grouping internally to create their parent-child data representations.

  Back to the top

 

Populating Input Element Collections

Input Select List and Input Radio Buttons elements differ from the other UI elements in that they require a datalayer to provide their selection items. The use of a datalayer allows some interesting flexibility in presenting the data. Here are several examples of this in action.

 

If the selection items are never going to change, then they can be "hard coded" into the definition using DataLayer.Static and child Static Data Row elements, as shown above.

 

It may make sense to place the selection items in an XML file, which has the advantage of being able to be edited outside of your Logi application. In the example shown above, a DataLayer.XML File element is used to provide the selection list items, 

<MyColors>
     <Option Color="Red"/>
     <Option Color="Green"/>
     <Option Color="Blue"/>
     <Option Color="White"/>
     <Option Color="Black"/>
 </MyColors> 

and an example of the supporting XML data file is shown above.

 

In the next example, above, a Sort Filter has been added to the datalayer, causing the list items to be sorted alphabetically.

 


     

Compare Filter elements can also be added. In the example above, one has been added to eliminate "Black" from the list of choices. Other tokens, such as @Request, can also be used in this attribute, which means the selection items can be changed dynamically.

Other datalayers, such as DataLayer.SQL, DataLayer.SP, or even DataLayer.Web Service, can be used to populate the selection items from various datasources.

  Back to the top

 

Setting Default Values

All of the user input elements, except Input File Upload, have a Default Value attribute, which lets you set the value that will be shown or selected when the page is first displayed.

Making the desired value appear or be initially selected can be as simple as entering that value into the attribute - "hard coding" what will appear each time the page appears. Note that in the case of the Input Checkbox, Input Select List and Input Radio Buttons elements, this value must be the one passed to the next page (from the Value column) not the displayed text. Tokens can also be used in the Default Value attribute.

In a situation where the user enters data then submits the page, for example to a Process task, and then task calls the data input page again, it's common to want to redisplay the values the user entered. To do this, use @Request tokens in the Default Value attributes of your Input elements and ensure that the calling Process task sends the values as Request variables.

 Note that this cannot be done by just setting the Request Forwarding attribute for a Target.Report element to True; you must use Link Params instead.

If you've used @Request tokens as described above, how can you get some default values to appear the very first time the page is displayed?
 

As shown above, the Default Request Parameters element can provide Request variables, for use as your default values, when none are actually passed in the query string. The parameter and its value are created as shown above.

Then the Default Value attribute of the first Input Text element is set to @Request.defaultSize~. This ensures that a value ("Regular") will appear in the Input element when the page is first loaded. If the query string that calls this page includes a Request variable of the same name, the Default Request Parameters value is ignored.

There's another option for populating the default values in an Input Select List element. The Default Values element, added as a child of the Input Select List, allows you to provide multiple default values when the Input Select List's Multiple Selections attribute is set to True. The default values are retrieved by a child datalayer beneath the Default Values element. If a Default Values element is present, then the Input Select List's Default Value attribute is ignored.

  Back to the top

 

Redisplaying Entered Values

After a user has entered values in Input elements, a report refresh or additional processing of some kind usually takes place. When the report is redisplayed, it's often desirable to redisplay the last values the user entered in the Input elements. There are three ways to do this:
 

Setting the Default Value Attribute

Most Input elements have a Default Value attribute and you can set its value to either the @Request token passed when the report was refreshed (e.g. @Request.theInputElementID~), or an @Request token passed as a Link Param from the calling report or process task.
 

Saving the Value in a Cookie

The following elements have a Save In Cookie attribute:

  • Input Chart List
  • Input Checkbox
  • Input Checkbox List
  • Input Color Picker
  • Input Combo List
  • Input Date
  • Input Email
  • Input Number
  • Input Password
  • Input Radio Buttons
  • Input Select List
  • Input Telephone
  • Input Text
  • Input Text Area
  • Input Time


Setting this attribute to True causes the entered value to be saved in a cookie, named for the element ID, when the page is submitted. This cookie survives the user session, preserving the value. You can then cause the saved cookie value to be used again in the next session by setting the Input element's Default Value attribute to the proper cookie token, such as: @Cookie.theInputElementID~
 

Saving the Value in Local Storage

The elements listed above were also given a Save In Local Storage attribute. Setting this attribute to True causes the entered value to be stored in the browser's "local storage" (if the browser supports this HTML5 technology). Data stored this way is preserved between sessions and is automatically restored as the Input element's default value when the page is redisplayed. The local storage size limit is approximately 5 MB total and all the values are stored as strings.

 Save In Local Storage is ignored if there's a value in the Default Value attribute. Do not use them at the same time.

When should you save values in local storage instead of in cookies? Local storage is the "cleaner", recommended method. However, you should only use it when you're reasonably sure your users will be using newer browser versions that support HTML5 and local storage (Internet Explorer 7, for example, does not). In addition, all cookie values are passed with every request from the browser to the web server, increasing network traffic, while local storage values aren't passed to the server at all. Finally, some developers may have a policy against working with cookies, making local storage a good choice.

Data is not stored in an encrypted form in cookies or local storage. The data can easily be found and read or edited on a user's machine, so don't store any sensitive information using these techniques.
 

This document is continued on page two.
 

  Back to top

Next  

 


© Copyright 2007-2019 Logi Analytics, Inc. All Rights Reserved