The remarkable story of the unremarkable data label.
A discussion on the role of a data label in your K2 SmartForms adventure.
The data label control.
In the pantheon of K2 SmartForms controls, the data label was thought to be one of the most basic, primitive, unsophisticated, meager, diminutive, insubstantial and even unremarkable in the eyes of newcomers to the land of K2.
This is how I would start a JRR Martin inspired story recounting he tale of a character whose outward appearance hid their greater purpose. A character who was underestimated and who possess the power to influence the direction of an entire kingdom, or in this case a solution. Fortunately, for you, I cannot find my copy of WordStar.
It has been some time since my last blog post, and recent conversations on this very control inspired me to try to put my thoughts into writing.
An attendee at a talk I gave had asked me to explain how to use a data label control. They were hesitant to provide any context around what exactly they were desiring to understand, opting for me to tell them how to use the control.
I struggled to give what I felt was an adequate answer.
How to use data label control? What appears to be a straightforward question is at the same time both simple and extremely complicated.
What became apparent during the exchange was that we were both approaching the topic from two different perspectives.
During a drive to the country the following evening, I started to dwell on that exchange.
What occurred to me was the person who asked the question had most likely read the legends of the valiant data label control. Read numerous blogs or watched any number of video tutorials on building with K2 SmartForms.
Whereas, I had spent years with the “Robin Hood” of controls and understood that the data label control’s notoriety was mostly hype and had only reached legendary status because of its band of Merry… controls?
This metaphor is struggling, allow me to elaborate.
The data label is just a control, and a very basic one.
A SmartForms control that is purpose built to store a value. The distinguishing trait between a data label control and a very similar label control is that while both can be used to display a value, only the data label control has the capability of being bound.
The developers reading this I am sure can follow what I mean by data binding, but for everyone, it means that in the context of K2 SmartForms, controls that can be bound can be easily dragged into various dialogs to configure rules, transfer values to other controls or similar acts of configuration.
The similarly named, but functionally different, label control, can only be changed by accessing its related properties as with most of the controls contained within in the Display category in the SmartForms designer toolbox.
Display class controls for the most part have properties that can only be changed during design time, and a limited subset at runtime. The label control itself cannot be used to transfer values during configuration like the data label control. Even though the label can be assigned a value, it isn’t through a direct means, and the use is much more limited to purely display behaviors for the presentation purposes.
The ability of a control to be bound isn’t unique to the data label, but a fundamental trait shared by all controls that are designated as “input controls” which are mostly contained within the toolbox Input category, with the exception of “attachment controls” which are a different conversation entirely.
Input controls have the capability of having a value assigned or retrieved from them just by referencing the control.
I feel that this is the point where newcomers to K2 SmartForms start to struggle. I struggle even now trying to explain it without getting into the weeds of control development.
The facts of the matter are that data binding isn’t unique to the data label control, but a capability shared by a whole class of controls, and therefore, that doesn’t make the data label control special.
The data label control, alone, is rather unremarkable.
I think that is why explaining how to use a data label control can be challenging since it is just a humble display control that can role play as a variable.
I can understand why someone might think there is something more to a data label control. Some special trick to unlocking its full potential. What of those legendary tutorials that told of the great escapades of the data label?
As I said, the data label is unremarkable, alone. “Alone” being the operative word.
You see, the data label’s greatest strength comes from its simplicity. For, as what appears to be a miscategorized display control, is a control that shares the innate ability of input controls, to store a value. The simplicity along with data binding is the control’s special ability.
The many tutorials surrounding SmartForms typically contain a step that instruct the developer to assign a SmartObject value to a data label. Then, at a later step, read that value as part of a rule or transfer the value to another control completing the objective of the exercise. The piece that is often overlooked in those tutorials is objective behind the steps.
A data label control is rarely the hero in the story but is more often a frequent and recurring supporting character. If you are a World of Warcraft fan, think more healer than tank when considering the role of a data label control.
The truth is that in the absence of a purpose-built SmartForms feature like variables, any data bind capable control could be used in a similar fashion to store a value, and the data label control is the next best thing a developer has to fill the need for a capability like a variable.
Other input controls can be bound, but some have strong type requirements or are just too complicated which can add unnecessary bloat when all a developer needs to do is persist a value.
That is the data label control’s purpose. The reason that it exists. No more. No less.
The conversation about how to use a data label control is a short one. A value is assigned or retrieved from the control. The data may be displayed. It may be hidden.
The true conversation is never just about how to use the control; the real conversation is about the situation in which a value needs to be persisted.
SmartForms controls are never used in a vacuum. The unremarkable data label control is always a part of something larger. In each quest, the only role it can play is the one for which it was designed, to store and/or display a value.
It is the requirements, the quest, that determines how best the data label control’s abilities can contribute to the goals of the developer. The control is merely a member of your party.
As the words on the sigil of the House of K2 reads, “Dependet” or it depends.
Data label controls aren’t used alone. They are a part of a team of controls making up your SmartForms solution. The data label control has a very specific set of skills that can come in handy in certain situations. The conversation on how to use it has to take into account the full picture of the problem a developer is attempting to solve as the choices made in other parts of the solution directly impact how the data label may be used.
The ultimate point I am trying to make is the data label control works best when it is combined with the full capabilities of the SmartForms designer in service of the business requirements. How it is used depends entirely on the other members of the party and the quest upon which you are embarking.
Together, your party and the humble data label can be remarkable.