Custom forms-system parameter (dictionary) Maintenance

I thought about this yesterday. I posted my data dictionary maintenance page. Today, let's talk about my data dictionary.

A data dictionary is used to maintain some fixed data that is frequently used in the system,ProgramA system function that can be conveniently called.

As to why such a function is required, I feel that the most convincing reason is convenient maintenance. A system, especially a large and chaotic system, it would be a lucky thing to clearly manage such classified data within it. It would be nice to know where it is when it comes to what to change. Besides, data dictionary can form a knowledge base of our system. It is helpful for the accumulation of knowledge for a long time, you can organize a set of basic general system modules that do not need to be reorganized to improve system development efficiency.

Speaking of user-defined forms, how does a dictionary use in form configuration? It exists as a parameter option and can be bound to a data source based on the parameter category. The system automatically loads the corresponding parameter information, which is described in the previous list field binding. Start to map:

It consists of three parts: System category, parameter category, and Parameter Details. To view the parameter details, you only need to double-click the parameter category line title to load the details. You can see the add (edit) page of the details:

I want to describe the field here. This field is generally added to all configuration pages to describe the idea during development and special reasons, makes system maintenance more convenient.

The entire editing page framework is generated by the automatic binding feature of csla, including field verification, which is quite powerful.