In the life of each developer comes a moment when he needs to make a form. It seems that there is something difficult - take it, throw it. And no, the form is, it is as alive. She has her own mood, her habits. Chose the floor - “F”, she was transformed, became a little different, curious, asked whether her favorite perfume, shoes with a heel, or not, married? But you are a man! And then you choose the floor "M", and, as it were, the questions should be different - single, favorite beer, favorite sport. Of course, you can make a bunch of molds for each sneeze, if “M”, then one, if “F”, then another. But this method will turn out to be a catastrophe at the support stage, and generally not in the spirit of beautiful code. Therefore, the form must be smart. Very smart. She should know who is touching her, what he wants, his secret desires. For example: there is a form for entering the address in five fields

• a country
• region
• city
• the outside
• underground

I choose a city, and why not form think out the region and country? Or chose the Vladimir region, why should I in the list of cities “Moscow”? The “Metro” field is also not relevant for the Vladimir region, and when Strunino is chosen, this is a mockery in general. Being engaged in the development of the client part in corporate WEB applications for 5 years, I still knew how to make the form smart. I hope my experience will be useful to you.

The main requirements for forms in ERP systems are as follows:

• Depending on the data, the set of fields and their attributes change (mandatory input, accessibility for editing).
• Depending on the values ​​of some fields, the values ​​of other fields are filtered.
• When you enter a form can change the values ​​of fields and their attributes.

Anyway, this is solved in two ways:

1. Many highly specialized forms arched with masters.
2. Universal forms that change their state over a variety of events (at least when values ​​change).

In the first case, everything is pretty sad. Take for example branching by gender. So as not to pester the user with unnecessary fields, we first find out the gender, and then we derive the form that is relevant for this choice. It turns out something like this:


Strictly speaking, this method of collecting information is called “master”. It is good for certain purposes (for example: after selecting a user’s task, well, or there is a lot of data in principle for one form, or forms reflect different business objects), but using it to impart dynamics is a dead end.

As a rule, there are fields whose logic is identical for all branches. The simplest thing is to duplicate this logic, but this is also the most incorrect. Very quickly, the developer will sink in his own code, but there is no need to talk about configuration through the settings, they are also duplicated. And branching tends to grow, and the tree - to become a complicated graph.
')
It is more efficient to have one form per one business object (entity) that changes its view on various events. Here comes the second method - universal, dynamically changeable forms (although the division is conditional, the master can be built on such forms). Implementing it is a bit more complicated than branching. I used to think “what’s so complicated here,” but in the process of solving this problem, the number of rakes, pitfalls and thin matter tended to multiply incredibly! After going through all this, I just can not share my pain and experience.

Elements of dynamics

Well, well, let's hide something there, show something, filter somewhere ... Stop! Not so simple. First, there are three main things to manage:

1. Visibility
2. Obligation
3. Availability

If everything is more or less clear with accessibility and compulsory, then visibility is not a trivial thing, and its management is closely connected with the method of placing the fields (went the pitfalls).

Metaphysically fields can be placed either fixedly or relatively. In addition, the width, and other size of the fields, can be specified in percent or in fixed values. There is a simple rule - fixed and relative values ​​are combined poorly. We must immediately determine - the form of rubber, or fixed in absolute coordinates.

Fixed forms

With fields fixed in absolute coordinates ( absolut layout is everywhere), it is easier to work in terms of placement - I made the grid for alignment and use the mouse to arrange the fields as you please, simply, at ease. It happens that the field should be no more than 40em, well, at least kill, but with fixed sizes, there are no problems, forty, so forty. Problems begin when visibility management begins. Here there are three fields, the central one is hiding, there remains a hole:

How to close this hole? Suppose we find out here, and if the structure is more complicated? Say 3 columns column and group fields? We will not measure and recount all this.

If a form has fixed dimensions and coordinates, then dynamic visibility control becomes the most difficult task. It must be immediately clearly presented and chosen, whether it is convenience and ease of loading, or dynamic visibility with all the buns.

Rubber molds

And what about rubber forms that are not fixed in absolute coordinates? Everything will be fine! The hole just collapses:


Collapsing is a major problem with changing field visibility. The user wants to see a beautiful, filled with meaning, not a hollow form.

This problem is exacerbated at a time when there are only few fields on the form. I want to have a beautiful, skater form. With a pair of columns of fields, with a bookmark panel, where there will be tabular parts, with groupings and other good.

On the form, all that is not fields are containers (for the time being we will consider such a concept). And containers contain fields. And the fields can become invisible, and the containers in this case will be empty. An empty container is worse than a hole in a form. He must go underground following his fields. But bad luck, containers can be nested, nested many times and nested many times (others do not come across to me). There is a need to bypass the container tree for the presence of visible fields in them. Bypass, fortunately, down. In any case, the form will tend to a hierarchy, like this:



It seems the algorithm is simple - change the state of the field visibility, walked around the container containing it down to the first visible field. Found such a field - that's that, the container is visible, not found - the container is hidden, and accordingly, we repeat the same procedure for the parent container. This is one of the solutions.
Sometimes you also want to hide not separate fields, but the entire container. There is a sign of a certain absolute hiddenness of the container, so that it does not come out even if the field in it is “visible”. Pretty quickly, this mechanism grows and becomes more complicated, it is better to immediately think about where everything will be considered, on the server or on the client, or adjacent. Sharing responsibility in this place is very important.

And where does the dynamics come from?

It is taken from the server (K.O.). In fact, this is a set of some rules, which (highly desirable) are set by the user through the interface. The simplest building block of dynamics is a Hub (Field-Condition-Value). Simplified this expression of the form: "If the value of the field is equal to the value, then the field is visible, otherwise it is not visible." A condition compares a certain value from some field on a form with a standard, and, depending on the chosen condition, the field to which this HLR belongs, changes its state (visibility, accessibility, mandatory). For example, in this form there is a PUS of hiding the “Metro” field, if it is not in the city. It is on such elementary conditions that the dynamics is built. Of course, it can be not only on the PUZ-ah. These can be document statuses, available fields in an operation, and a lot of scary words. But at the client level - this is all an abstraction and not where the essence comes from, it is important how to work it out.

It is worth noting that the HSS can control not only the field, but also the whole container, which is often convenient, although it can ideologically be challenged, because the container is not an element of business logic.

Summary...

Letters above I talked about how to do the dynamics for the forms. The task is rather trivial and largely depends on the components you use for the interface. I have described how this is done on the Web, although it is so general that it suits a variety of systems. I need to think about the nuances described by me immediately, as you start thinking about starting to think about the form architecture in your system.

A little later (if there is interest) I will tell you more about the sources of dynamics, namely, field events, dynamic filters, I’ll talk more deeply about HSPs, and touch on statuses and operations. All these are common topics for accounting systems, and not only.