We talked earlier about Designs vs. Models. We’ll dive into Models in more detail now.
As we mentioned, a Model is an instance of a Design. Child Rules provide Parameters to a Design and those Parameters are used to drive the creation of an instance of that Child, which we call a Model. The term Model includes the entire tree of assemblies, sub-assemblies and parts since each Design in turn may have Child Rules of its own. We often refer to this as the Model tree.
How does the top level Design gets its Parameters? kBridge does this via a special internal root-parent that provides the Child Rule for the root Model based on the Parameters of the root Model’s Design.
In a Model, some of the Rules have been evaluated and have a value. We refer to the grid that allows us to review the Rules as the Rules panel.
Each Rule has a value, a data type, flags, and an owner. The owner indicates where the formula came from. We’ll talk about this in more detail in just a minute. However, first let’s talk for a minute about Model Rules.
Model Rules
A very special and powerful part of kBridge is our ability to have Model Rules. NOTE: Model Rules are an advanced topic. You may want to skip forward to Owner below.
At first the term Model Rule might seem like an oxymoron, since we just explained that Rules are associated with Designs, not Models (instances). However, in some circumstances, it is really good to be able to add a Rule or override a Rule on one instance only. This is a feature we often use when making custom interactive user interfaces for example.
Let’s consider a simple example. What if we have a single table Model and we want to change the length Rule on only one leg of the table? In other words, all the legs will calculate their length based on the length Rule supplied by the leg Design. However, we want to be able to override that Rule for one leg. To do that, we add a Model Rule on that leg.
The Model Rule will be associated with only that one Model. It will not change the Design and it will not be stored or managed with that Design; it is stored and managed with the Model only. If we add a Model Rule for Length to Leg, it will override the Length Rule in the leg Design and the new value will be calculated by the formula of the Model Rule.
So, if for example our new Rule adds 10 to the length, when it is applied only to the second leg, then we override the height Rule on the second leg with the new Rule. Only the second leg will be longer – and only on that one specific table Model (instance).
Model Rules are not commonly created by Rule developers. Instead, they are usually created "on the fly" by user interfaces that allow end-users to add content or customizations specific to an end-users Project. If a customer is selecting options and adding components to an order, Model Child Rules can be used to dynamically add them. If they want to customize a feature on an existing Child, Model Rules can be used to override individual values.
Black Box versus Gray Box
We call applications that have a UI that only allows us to provide inputs and wait for outputs to be a black box UI. A gray box application allows end-users to define the Model.
As another example, we once had a very large and complex application for field-erected cooling towers. These towers have thousands of parts and there were only a couple of active runtime users of the application (the company doesn"t Design these every day). Building a custom UI wasn’t really needed. However, we did need to enable the run-time user to have control over some of the Rules. In some cases, they needed to override or modify a Rule on one Model only. Maybe a basin within the tower had a special obstruction that could not have been anticipated by the developers. It wasn’t worth it to re-write the core Rules again to take that one case into account, but with Model Rules, the user could override the appropriate Rule and update the Model so that it could generate a solution.
