background
The previous article introduced the overall design of the view ( https://blog.csdn.net/seawaving/article/details/130764669 ), and today we will focus on the specific view configuration functions.
view type
According to different purposes, the views are classified, and the modeling produces the following types of views
-
list view
-
new view
-
modify view
-
view view
-
tree view
-
tree table view
-
reference view
-
Tree Reference View
-
Tree table reference view
-
Master-slave view (to be implemented)
-
Custom View (to be implemented)
list view
Introduction
For most business entity management, there is a corresponding function menu in the system. The most common case is a list page, such as the application management function under the interface platform module. As shown in the figure below, this page corresponds to the list view, including
common Query, add, modify, and view pages (the delete function is not a page, but just a function button, located on the list page), corresponding to adding view, modifying view and viewing view.
The list view is the most commonly used and the most complicated, let's talk about it in detail below.
overall configuration
The list view configuration function is abstracted, and it is mainly divided into four areas of configuration, which are page buttons, query conditions, query results, and row buttons.
Button configuration is divided into page buttons and row buttons. Page buttons are located between the query area and the query result table, and usually correspond to global operations or batch operations, such as refresh, add, batch delete, import, export, etc. The row button is solidified in the last column of the query result table as the operation column, used to record operations on the current row, such as modify, delete, enable, disable, etc.
The platform will automatically read the attributes of the entity corresponding to the view, and then display them as list items. These list items can be quickly copied to the query condition area and query result area by dragging, and provide full copy and full clear functions. It can be dragged and sorted, and the attribute configuration can be modified.
button configuration
The page button and row button are configured as follows.
The code is the unique identifier of the button, and also corresponds to the method name triggered by clicking the button.
You can directly write the js method body in the content attribute. This attribute is not necessary. Commonly used method implementations are often implemented in mixins. Only when you customize the method or want to override the default implementation of mixin, you need to fill in the content.
Icon, if set, will generate a button with an icon.
Whether confirmation is required, and if so, further confirmation information needs to be entered, and the confirm dialog box will be called when the code is generated.
Whether there are more, the main reason is to consider that some functions have more function items, so there are more corresponding buttons, which may not fit in one row or affect the appearance and intuition. In order to save the space occupied by row buttons, some uncommon functions are put together in one "More" drop-down menu.
In addition, in order to improve configuration efficiency, the system also provides a button template function, which makes common buttons such as add, delete, refresh, etc. into templates, which will be described in detail later, and here is just a brief mention.
Query conditions
Data query is an important capability provided by the system, put it in the list view, set up a query area at the top, and put some query conditions in it. The number of query conditions depends on the specific function, ranging from 1-3 to more than a dozen. To reduce space consumption, the query area is collapsible.
The properties of the query conditions are as follows:
by default, the data type, control type, etc. are synchronized from the entity properties, which need to be adjusted according to actual needs, such as hiding as an implicit query condition, controlling read-only to limit the query range, setting default values to automatically fill, etc.
For text attributes, visually select equality, fuzzy matching, starts with and ends with, and flexibly sets matching rules.
For the properties of the data dictionary class, if it is a drop-down list, the platform will automatically add multiple selection controls.
For date-type and numeric-type attributes, querying a single value has no business meaning. For example, the contract amount is equal to 1 million, but a range query is required.
The query area will automatically generate the selection of start and end ranges. When using it, you can flexibly choose less than 1 million or more than 5 million, and you can also control the combination between 2 million and 3 million.
search result
The query result is an important part of data display. The configuration is as
shown in the figure below. Most of the attributes are also synchronized from the entity, and only a few attributes need to be configured on demand.
The name corresponds to the column name of the table and can be adjusted according to the actual situation.
The encoding corresponds to the attribute name and cannot be modified at will. For the data dictionary, the platform will automatically take the attribute of the dictionary code + Name according to the agreement, that is, the converted display name. This attribute is processed in the link of converting entity to vo in the controller. Similarly, the same process applies to external associated entities, such as the user's organization attribute, but the converted display text is the main attribute of the entity.
The width is the column width of the table, which can be set as required. When the number of columns is small, you don’t need to set it, and el-table will distribute each column evenly. If it is set, there will be a problem that the table will not be satisfied with the page and affect the appearance. If you don’t set it when there are many columns, based on the principle of equal distribution, the display of each column is very narrow, and squeezing them together will also affect the appearance. At this time, you need to set it as needed, and a horizontal scroll bar will appear.
Whether to support sorting, if yes, enable backend remote sorting. What needs to be noted here is that for data dictionaries and external associated entities, the system automatically considers that backend remote sorting is not allowed. The main reason is that this part of the attribute sorting business has little meaning. The secondary reason is that the attribute name has been processed with the above-mentioned additional Name. After passing it to the backend, the backend will report an error because the field cannot be found. This place can be considered in It will be optimized later so that it also supports sorting.
The formatting method is used to format the output. Currently, two types of dates are implemented. The formatted output is yyyy-MM-dd HH:mm:ss for seconds and yyyy-MM-dd for days. You can directly select from the drop-down. Later, it can be expanded as needed, such as adding commas for thousandths of currencies, RMB/dollar symbols, controlling decimal places, displaying percentages, etc.
Whether it is displayed in a floating state, not much to say, it is a practical function that pops up a floating frame to display the complete content of the cell when the mouse is hovered over.
Whether to display, literally, this place only controls whether to add the query result column display by default. When users are using it, they can still add this attribute to the list through the column configuration function at the top right of the table.
Add, modify, view view
These three types of views are very similar and well understood.
It is simpler than the list view, with less button configuration, which is equivalent to the system preset save and close buttons.
In fact, the function is also reserved, which can be expanded to be configurable as a button. Specifically, we will see the necessity of doing so later.
It is also possible to copy entity attributes in batches or clear them in batches to modify the configuration of a certain attribute.
You can configure the newly added view, and then use the function of copying the newly added function to quickly generate the modification and view view.
There is actually an important point here, that is, adding, modifying, and viewing, whether to share one view or multiple views, and there are two options for multiple views, one for adding and modifying, and one for viewing.
Both options actually have pros and cons. According to the principle of single responsibility, they should be separated, but in most cases, the attributes and logic of adding and modifying are the same, so many development platforms and development frameworks are reused. Reuse means that if-else statements need to be written for differences, such as saving of new additions and modifications, the called services are different. Once the codes of some entities are created, they are not allowed to be modified, and need to be set as read-only in the modification view. Write each logic separately, but adding new field attributes later means modifying multiple views simultaneously (adding, modifying, viewing).
On this issue, I finally chose to separate. With the support of platform code generation capabilities, development efficiency is no longer a problem, so I still follow the principle of single responsibility, which is logically simple and does not need to write branch statements according to the situation. It is easy to expand, In the case of scenarios that require fine-grained control permissions, the handling can also be simplified.
View originally wanted to do differentiated display, converting all attributes into text, such as data dictionary encoding, external entity association, removing drop-down list, date control, etc. But in the actual implementation, we encountered problems, such as whether some attributes are displayed or not, affected by the value of other attributes, this part of the logic needs to be processed, and then gave up, the content is still the same as the modified view (note that it is the same, not public), just Removed the save button. After all, in most cases, there is no need to separate viewing permissions from modification permissions.
Tree View, Tree Table View
Introduction
For self-associated entities, such as organizations, the actual data is hierarchical and will be displayed as a tree. The view can be automatically handled by whether the view is superior in the entity model attribute, and no additional configuration is required.
If the list view is just a table tile, it is difficult to show the hierarchical relationship, and the intuition is poor. At this time, a tree table view is needed, with a tree on the left and a list on the right. In fact, the tree table view is a composite view composed of a tree view and a list view.
configuration
Most of the configurations of attributes are mentioned above, so I won’t repeat them here.
Whether to display or not A custom is added here, and js expressions can be written, mainly considering that whether some attributes are displayed or not needs to be determined according to the values of other attributes when editing entities. For example, whether confirmation is required during button configuration will affect the display and hiding of confirmation information attributes.
Reference View, Tree Reference View, Tree Table Reference View
The reference view is a selection page used for other entity association attributes. If the user needs to specify an organization, it can be divided into three types: general reference, tree reference and tree table reference.
General reference : If you configure the data permissions of the application on the interface platform, you need to select the application, and a data list is enough, corresponding to the reference view.
Tree reference : When users maintain, they need to select an organization structure and need a tree, which corresponds to the tree reference view.
Tree table reference : When selecting a user, the left tree and right table are required, the left is the organization tree, and the right is the user list, corresponding to the tree reference view. The tree reference view is actually a compound view, which is composed of tree view and list view.
Master-detail view, custom view
In addition, there are two views. The platform has been planned but has not yet been realized. I will mention it here by the way.
One is the master-slave view. For the entities of the master-slave relationship, such as sales orders, the master-slave view is used, which is actually similar to the tree table view and is also a composite view.
The second is a custom view, which is used for some personalized pages and cannot be configured in a standardized manner. It is implemented through native development, and the specified path is incorporated into the entire system.
Development platform information
Platform name: One Two Three Development Platform
Introduction: Enterprise-level general development platform
Design information: csdn column
Open source address: Gitee
open source protocol: MIT
welcomes favorites, likes, and comments. Your support is the driving force for me to move forward.