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.

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?