entity model , Model view , Form model , Form rule engine , These parts are the core content of the custom form , Previous articles have introduced the solid model , This article introduces view model management .
We usually see some management systems or some done by most programmers CRUP operation , For example, list management, which we contact most 、 Forms Form management 、 Tree management, etc , These functions are the most common and cumbersome in a background management system , For a background management system , Probably 60% Both sides are doing such tedious and boring work , In fact, we can summarize these functions , Abstraction , List management is nothing more than the definition of various basic query fields 、 Advanced query definition 、 Some basic function buttons 、 For example, add or import / export Excel etc. 、 Column management 、 Sorting, paging, etc , For forms Form management , Nothing more than field sorting display 、 What controls are used to display fields 、 Verify on save 、 Add or modify , These functions can be abstracted according to large aspects , In practice , Open whatever function you want , What's more, we can make a template , Common functions are automatically generated according to the template , Most of the process of configuration can be omitted .
Entity model management is the abstraction of these specific typical functions , The real business dynamically generates specific business function modules according to the entity model .
Let's start with the overall design
Description of key fields in the view ：
ViewType（ View classification ）： Views are divided into list views 、 form view 、 Tree view , You can also flexibly add other types of views later .
Version（ edition ）： Every time you modify any information about the view , Will regenerate a version number , The browser stores view information , One page per dozen days , The local form version and view version will be passed to the server to compare the version number , If the version number changes , Re request view data （ Generally, after system interaction , View and form definition information rarely changes ）.
PropertySettings（ View properties ）： Store some styles of the front end , Like the list view , Storage front end List Some properties of the control , Front end rendering , Read the property and apply it to the control , Generally, it needs to be set in combination with the specific front-end frame .
RelationInfos（ The correlation information ）： Views may be associated with other views , For example, in the form view , The data of a field is obtained from other views , Here, the associated view Id Associate to this view .
Rules（ The rules ）： Rules for defining views , If you click the Edit button , Open the dialog box 、 Get form data 、 Bind form data to form view .
WrapInfos（ View wrapper ）： The view is displayed in the alignment box , The view is displayed in a specific style Div Medium or Box in , The front end when rendering the view , If there is a wrapper , The view is wrapped in a wrapper before rendering .
Controls（ View control ）： Different view controls display different areas , You need to define controls in combination with specific views , When rendering different views from the front end , Read different types of view controls , Display view controls in a specific area .
Extension1、2、3、4（ Extension field ）： For different views , Store different content , Like the list view , Store query information 、 View specific column definition information 、 The form view stores the table row definition information . Use different extended fields according to different view types .
form view ：
The view of the form class consists of rows and columns , Each row has one row of data , Row properties can be set for each row , The front end dynamically renders a row of data according to the row attributes .
Columns can display the specific fields and the controls and validation expressions used by the fields . Columns in addition to display fields , You can also display sub views or sub forms . View 、 Forms 、 All behavior of the control is controlled by the rule engine .
List view ：
The list is generally divided into query areas 、 Advanced query area 、 Table area 、 Paging area 、 List control area , These areas can generally be fixed , Each area can be configured , For example, query area , You can define which fields to query , Fields to query Where What are the conditions , Where can advanced queries use comparison criteria , What controls to render with .
Generally, the content can be displayed directly , But some special columns , It needs to be defined separately , For example, a column is a data dictionary , A column of different conditions with different colors to display the content, etc .
Let's introduce it here , Refer to the architecture design drawing for specific details , If you have any questions, you can consult me , Custom forms are inherently complex , There are many concepts , There are many things that need to be abstracted , Here we mainly provide some design ideas .
Open source address ：https://gitee.com/kuangqifu/sprite
Experience address ：http://184.108.40.206:8031（ The first load may be a little slow , Alibaba cloud's worst server ）
Custom form article address ：https://www.cnblogs.com/spritekuang/
Process engine article address ：https://www.cnblogs.com/spritekuang/category/834975.html（ use WWF Development , Deprecated , Changed to Elsa Realization ）
Github Address ：https://github.com/kuangqifu/CK.Sprite.Job