This post is the sixth and final installment in the Build a Reporting Engine Using K2 SmartForms series.
In previous posts, I talked about some aspects of the T-SQL used to support the engine, and touched time and again on how the actual job of the interface is to build a SQL
WHERE clause to append to a
SELECT statement and execute to return data to a list.
Today I’ll talk a bit about the interface.
Here’s what the entire interface looks like:
The top half (above the SUBMIT button) is used for building the report query, as previously stated. Notice it shows a header row with toolbar buttons and labels, and one row with form controls aligned beneath the labels.
The bottom half of the form isn’t really much to write home about; you might imagine the SUBMIT button actually assembles the completed
WHERE clause, sends it for processing, and causes the result set to be returned into the list view at bottom (pictured empty and with the text “COLUMN” in place of actual data column names).
So our focus is going to be on that top half of the form.
This interface is comprised of two item views on a SmartForm.
- The header view at the top acts as both a controller and a header for the rows beneath;
- The row view contains controls which align to the labels in the header and is used to combine an attribute, an operator, and a value into a completed comparison. (Need to review the terminology?).
The header view features several toolbar buttons and labels that serve as headings for the controls on the row views below it. The toolbar buttons are:
- Add, which is used to show additional row views
- Reset, which essentially re-initializes the form and hides additional row views
- Load, which is used to load saved report queries into the interface
- Save, which is used to save the current report query to the database, and
- Help, which shows a subform with information to offer self-service guidance to the user.
With all of the toolbar buttons, you might imagine the header view as a sort
of a nerve center for report engine operations.
The header view also contains a series of labels which are aligned with the controls on the row view(s) beneath it.
Notice the picture shows the header view with three row views aligned beneath it.
This row view is actually attached to the form multiple times — three, in this example — which opens up the possibilities for using rules for hiding and showing each row as you need them.
The image of the full form only shows a single row view by default — the Add toolbar button in the header view is used to evaluate the condition of each visible row and determine whether another row should be added (made visible).
Among the things I did in my row was create a series of different value controls that accept different kinds of input. The default control is a simple textbox, but it could be switched to a radio button group or a picker if your data supports it. For example, if you have an attribute that is essentially a Boolean — say “Yes” or “No” or “True” or “False” — then a pair of radio buttons for the value control makes much more sense as it forces the user to pick only one value or the other instead of you trying to evaluate whatever the user typed into the textbox.
Notice that the row views are missing the top portion of the row. Contrast with the header view that has toolbar buttons in that shaded top area. I was able to hide the top portion using this JQuery command in a hidden literal to hide the area in the
Well, I think that’s it. In this series of posts I’ve tried to hit the highlights of how I created a reporting engine using K2 SmartForms with a relational database back end, like Microsoft SQL Server. I hope you’ve found these helpful, and that they will guide you into creating a reporting engine of your own.