The model-driven topic has three chapters:

1. Front-end components

2. Model and data adaptation

3. Background model management


The core of MIS system is to add, delete, change and check data with many fields


And our customers’ needs often change: “When this piece of data is available, this radio box is going to be a drop-down box. More data will take search oh.”

The point of model-driven development is to improve the efficiency of development. Compared to templates that generate a lot of junk code (e.g., Codesmith), model-driven generated pages are more maintainable, but the learning threshold is also higher.


At present, in practice, forms, forms and searches can form interfaces based on models and certain rules. For example:

Form – Basic form:


  1. In order to be beautiful, it will be arranged in accordance with the rules
  2. Each small white box is an input type control, which can have many types, such as: text, radio groups, upload, and so on
  3. Form verification and prompt information are required, especially dynamic verification conditions. If several input items are met, a certain item must be filled
  4. Field value linkage
  5. Forms are displayed in groups
  6. You can embed it in a modal popover
  7. Mobile terminals are generally tiled


Search – Basic form:


  1. Search is still an input component of sorts
  2. A few cases require linkage selection
  3. Search criteria, background may be multi table joint query. Field names need to be processed during search; otherwise, background judgment is difficult


Form – Basic form:


  1. Table columns need to control sorting and filtering
  2. Search is mainly combined with forms, query conditions permanent and so on
  3. Back-end paging of table data
  4. When the table is edited, the control will have the corresponding input type

How many component types are there and are they sufficient?

The reference Ant.Design front-end component library is already rich, but we only need to commonly integrate it. Representations that are too complex can be customized in a specific project as extended Slot forms.

According to the requirements of common forms input, the following figure is shown:


Are components replaceable?

Every time this topic comes up, one scenario is if new components come out after 3-5 years, can the product be replaced cheaply?


My conclusion: this is bullshit, and when every component is replaced, the entire product UI is changed, and maybe even the technology stack is changed, it’s not that expensive

In my opinion, it is more practical to replace some of the components during the running of the component library. For example, the tree component has poor performance and needs to be replaced. Whether it can have minimal impact on existing products.

This question has been hanging like a sword of Damocles over our heads. To be backward compatible, the interface must be predefined.

Based on Vue, the mainstream technology used by the company, THE TG-Turing library was defined to implement abstract forms, tables and searches. The real component implementation is stripped to another library for easy replacement later.


The interface tag component defined in TG-Turing was used in the actual project to upgrade and replace components without the awareness of the upper application.

Each form component that can be accessed is defined as a ConnectItem:



See:

Tg – Form GitBook​res.wisedu.com


Here’s a simple example:

let fields = [ {"name":"WID","xtype":"text","caption":"WID"}, {" name ":" ACCOUNTID ", "xtype" : "text", "caption" : "login name", "dataSize" : 40}...].  <tg-form :fields="fields" v-model="formData" :column="2" :readonly="true"></tg-form>Copy the code



I also noticed that Mozilla has a similar React project that focuses on form data structures and supports loop nesting, which is interesting.

react-jsonschema-form playground​mozilla-services.github.io



The next chapter will talk about how to use models to drive front-end components