Multiple list display screen, detailed display screen, registration screen can be created for one model.
When creating multiple screens with one model, first define the main model (hereinafter referred to as "main model"), then copy the definition content and call it a new model (hereinafter referred to as "submodel" Define it. Multiple submodels can be prepared for one main model.
Select one main model.
Select "Template> Submodel" from the gear icon.
By default, a model given "- submodel" as a model name is newly created.The model ID is given the number "1".
Open the submodel definition.Please first change the model name and model ID appropriately.
Here I tried adding the name "[sub]" to every item name.(The item name can be changed.Item ID can not be changed.)
In addition, I deleted the item named Remark.(You can reduce items in the submodel.)
First, let's register the data from the submodel.
Figure 8 shows an example of registering one data from a submodel.
Next I will search the main model.
In the main model, data registered from the submodelshareYou can see that it is done.(The table is shared, so it is shared.)
The smartphone version screen can be applied to a subset (a part) of the PC version.We will use the PC version model as the main model and the model used on the smartphone as the sub model.The submodel is handled as a part of the main model item.
Then enable the "Use on smartphone" setting for the submodel.
You can create multiple list display screens on one model using submodels, and so on.It is also useful when you want to divide the screen to access for each user.
It can be applied to a design that shows the main model to authorized users and shows submodels with few items to unauthorized users.
Here is an example of using submodels to divide screens that can be operated for each user's authority.
In this example, we have two accounts "Yamada" and "Suzuki".
|Yamada||Customer management||Customer (main model)|
|Suzuki||General||Customer (for general users) (submodel)|
Fig. 11 shows an example of operation of the customer list display screen by the user Yamada.
Fig. 12 shows an example of the operation of the customer list display screen by the user Suzuki.This submodel does not contain "phone number" item.
Figures 13 and 14 show the principals of each user.
Depending on the principal, you can change the models that can be operated.For users Yamada and users Suzuki, the model displayed in the logon menu differs.User Yamada manipulates the main model and user Suzuki manipulates the submodel.
The system administrator can operate all models.
For the "customer" model, we prepared a submodel "customer (for general users)".(reference:How to create a submodel)
Fig. 19 shows the main model "customer", and Fig. 20 shows the submodel "customer (for general user)".Submodel has been deleted "mail address" and "phone number".
Delete the principal "general user" that was originally from the main model "customer".
We will prepare a new principal "customer management".Allow all operations.
The principal of the submodule "customer (for general user)" invalidates the authority of the update system.This will allow you to only view.
After creating the submodel, you can change (your own) main model. Specify "Main model name" from "Screen> Other> Relationship of model".
Figure 12 shows the customer (submodel) list display screen.If you press the "details" button here, it will transition to the customer (main model).(FIG. 13)
Prepare the submodel.
In the submodel's "Screen> Search/List display> Detail button", specify its own parent model from "transition destination model ID".
In the foreign key linkage, you can specify the transition destination of "detail" button and "update" button in the child model list display displayed at the bottom of the parent model details screen.
Submodel is different from main modelGroup authorityIt is possible to set.
For example, you can say that the main model is authorization 3, submodel 1 is authorization 2, and submodel 2 is authorization 3.
For essential checks, three types of values can be set: "○", "warning" and "unspecified" in the specified place.When "○" is set NOT NULL constraint is set in the corresponding column in the database table definition.Therefore, if "○" is specified for any of the models, "○" must also be specified for other models in the main sub relation.This is for using the same table.
Warnings and unspecified can be combined.For example, it becomes as follows.