# Developing Web-Based Process Management with Automatic Code Generation
## 3 Architecture
### Automatic Code Generation to Create a Task
* The functionality and configuration of plugins are often organized around specific templates and rules. In this context, the PluginTemplate and Action tables are an excellent example of this type of configuration. The PluginTemplate table (Figure 16) defines the basic templates of plugins. For example, a plugin with a PluginTemplateID value of 1 indicates a form-based structure. A form-based structure is typically used to receive user input and process data. Therefore, it is natural for a form plugin to require specific actions, such as submit, delete, lock, and unlock. Figure 2:4 PluginFunctionMap data table. Figure 2:5 PluginAction data table. The Action table (Figure 17) identifies these actions. Each action has a unique ActionID associated with the DefaultPluginAction table (Figure 18) to determine which plugin template supports which actions. For example, the form template with PluginTemplateID 1 supports actions with ActionIDs 8, 9, 10, and 11. They automatically select the HTML template that best suits the user's needs based on specific business rules. In particular, when creating a data table, this automation platform automatically selects a form-based HTML template to ensure consistent input data collection. When the data set needs to be listed or queried, another listing-oriented template is preferred to ensure the data are presented appropriately. Workflows defined in the process editor also benefit from this automation. When a conditional workflow is created, the platform automatically adapts an HTML template with functional buttons such as \"approved\" or \"not approved\". In short, these automated code generation platforms select the most appropriate HTML template based on business rules, thus speeding up and standardizing the software development process. Such a structure allows the software to be modular and customizable. It also provides a framework for determining which software components fulfill which functions. This allows the software to have consistency, ease of maintenance, and scalability. In the fourth stage, JSON data modeling was adopted, a popular approach in response to today's data storage and cross-platform data transfer needs. The JSON generation process, triggered from the web interface through the code generation editor, automatically converts the data in the database into JSON format. As a result of triggering the \"Generate JSON\" command through the code editor of the low-code platform, the information of essential components such as Element, Plugin, Function, and Action is automatically converted into JSON format. This conversion process is structured through  
Figure 2:6 PluginTemplate data table. Figure 2:7 Action data table. the main sections of the JSON schema, namely Description, Plugins, and JobSpaceAction. The detailed structure of the generated JSON schema is shown in Figure 2:8  
In the fifth stage, the JSON conversion performed through the web interface is integrated into the system. The HTML code generation process performs automatic code generation based on JSON data sets. This coding is based on tags that define how the documents interact and how the content (text and images) is positioned. For example, for a button component, the relevant records in the database are automatically mapped to the specified action functions and plug-ins. The HTML template example in Listing 1 illustrates a templating mechanism used in contemporary web applications for dynamic data integration. The corresponding HTML element is decorated with different data-* attributes. The [ ] constructs inside these attributes represent variable or function calls of the templating language.