In most cases, grid applications developed with Nitro App Builder have static columns that never need to change. That is, a "Customer Number" column will always hold the customer number or customer ID; a "Product Number" column will always hold the item number or SKU, etc.

But in some cases you may have grid columns that, ideally, would have different column headings depending on the type of data being rendered.

Lists or grids of business data are often pretty straightforward to filter, particularly when applying single-column comparisons. Do your users need a way to limit a list of customer orders to a specific destination country and shipping date? No problem! Two simple column filters — one over the ship-to country, one over the ship date — and the users are able to retrieve what they're looking for.

But occasionally users may come to you with some more unusual filtering needs...

If your company's ERP system database had its genesis in the 1980s or early 1990s, and it hasn't "evolved" a whole lot since then, you likely have a number of files where date values are stored inside numeric fields. Whether your dates are parsed into separate year/month/day fields, or held in single YYYYMMDD, CYYMMDD fields, etc., you're already well aware of the hurdles you must jump over when trying to do otherwise simple things like date arithmetic, filtering, sorting, etc.

In today's internet-connected society, just about any kind of information you need to know can be pulled into your system through a web service API. These APIs make it possible to pull public (or private) record sets into your Valence apps from databases that are not necessarily located within the walls of your company's data center.

Without doubt, the most effective way to create powerful web or mobile apps with minimal code is achieved by harnessing the power of SQL in your data sources. We've used variations of SELECT * FROM DEMOCMAST in countless examples here over the years, and likely you've leveraged that concept in many of your own applications as well. The columns returned by SQL automatically propagate into your widgets, and with some quick configurations you can have a ready-to-run app for your users in no time.

If you spend enough time handling end user app requests, you're bound to run into a case where someone wants to see data from a detail level file inside a grid displaying header-level data. For instance, a customer service rep might ask you to integrate a list of line items into a customer orders app that currently only shows header information.

Upon hearing such a request, you might respond, "So you want to be able to click on an order row to drill down and see all the items?"

When creating grid apps, it can be tempting to pull in every conceivable column someone in the company might want to see. Consider, for example, the case of a grid of inventory items. You know users in accounting like to see dollars, while warehouse users like to see quantities, people in purchasing like to see dates, etc... Everybody has something special they want to see.

Business systems are replete with lists of data, many of which entail users editing, adding or removing records in one or more underlying physical files. Conventionally, a maintenance app for, say, basic customer info would be initially presented to users in the form of a grid. Users would then click on a row to bring up a pop-up window, where the respective data is arranged in a form for editing.

Since the official Valence 6 release in September, many sites currently using a prior version of Valence face the somewhat daunting task of getting users to change their URLs to the new instance. If you're not using some sort of an alias or permanent redirect in Apache — meaning the port number for your Valence instance is part of the URL — then you're looking at potentially hundreds of users needing to update their browser bookmarks to point to a different port.

Programs running on IBM i routinely need to retrieve the specific user ID associated with the person executing the code. In traditional interactive 5250 programs, the user ID is often accessed in RPG through the program status data structure, or by making a call to a CL program that uses the RTVJOBA command. These "old school" green screen approaches for obtaining the user ID may need to be tweaked a bit when running within a web environment.  

A checkbox filter is one of the most intuitive user constraints you can add to a grid. The user simply checks a box and the rows of the underlying grid are immediately filtered to reflect the condition labeled on the checkbox.

Imagine going to a buffet and being told you can only choose ONE item for your plate, and if you wanted more you'd first need to take that single-item plate back to your table, consume it, then return for the next item.  Wouldn't it be great if you could just load up your plate with two, three, four items or more and consume them all at once?  

If you're creating NAB forms or custom apps that send emails using the VVMAIL service program module, as demonstrated in the "Send Email" utility nested inside the Examples app, you can set up a back-end routine to globally intercept all outbound messages using an exit program. The exit program you create can be used to override the mechanism through which emails are sent, or to store pertinent details in a custom "outbound email log" for auditing purposes. 

In our previous newsletter tip we explored how to create an app in which users can upload files to specific locations on the IFS. Now we'll take a look at how to create a separate app that can put those uploaded files to use, in this case rendering them as thumbnail-size images inside a grid column.

Even as companies move toward a more paperless workplace, printed documents and paperwork remain an inevitable part of doing business. Whether it be a supplier invoice, a bill of lading, a certificate of quality, a signed contract, a proof-of-delivery or what-have-you, many business transactions are still supplemented with a piece of paper somewhere.

The coronavirus pandemic and accompanying "social distancing" has created unique business challenges on many fronts.  This is particularly true for companies who weren't already set up to support large swaths of employees suddenly looking to access their IBM i-based ERP systems from home.  

If a picture is worth a thousand words, how much more valuable is a button with an icon on it, compared to a string of words nested inside a row menu?  While a thousand times valuation differential may be a stretch, there's no doubt that a visible action button on a grid row is going to be considerably more intuitive to users, particularly new users who are exploring apps for the first time.  Such buttons also offer the added value of requiring one less click to trigger a row action.

With the end of the year approaching, most companies find they have a rare opportunity to do some significant system maintenance as users go offline for the holidays.  In addition to, say, upgrading to IBM i OS 7.4, this may also be a good opportunity to rearrange your Valence setup so it's following a "best practice" configuration.  In a proper setup you can download and test new Valence builds without affecting any of your production or test instances.

When creating an app to convey a typical collection of IBM i business data to users, the most common approach using Valence's Nitro App Builder tool is to build an SQL statement to pull in the pertinent information, pop the resulting rows into a multi-column grid, give the user a few filter options and call it a day. 

Just about every modern office job involves users interacting with a computer for the bulk of their work day.  So excessive waiting for the computer to respond to actions can lead to both user frustration and decreased productivity. 

In short, users like speed!