JP4502763B2 - Database usage system - Google Patents

Description

  The present invention relates to a database utilization technique, and in particular, a front-end server is installed between a client terminal and a database server, and registered data in the database server is used from a Web browser program of the client terminal via the front-end server. The present invention relates to a database utilization system having a mechanism.

Originally, in order to use (refer to or update) a database managed by a database server in a client terminal, a dedicated application program has been set up in the client terminal.
This dedicated application program is generally coded in a fourth generation language suitable for the design of so-called user interfaces, such as the arrangement of operation buttons and the configuration of input / display fields, such as Visual Basic (registered trademark). As shown in Patent Document 1, it has an advantage that a screen excellent in visibility and listability can be displayed on a display when referring to and updating a database.
In recent years, however, the inefficiency of installing dedicated application programs on individual client terminals has been recognized, and the use of Web systems centered on the Internet has led to widespread use of general-purpose Web browser programs. There is an increasing demand for using the database to refer to and update databases.

FIG. 1 shows an example of a database usage form using such a Web system. A front-end server 16 having a Web server function and an AP (Application) server function in the preceding stage of a DB (Database) server 14 is shown. The server 16 is connected to a large number of client terminals 12 via a communication network 18 such as the Internet or an intranet.
Each client terminal 12 has a web browser program set up. When a database use request is transmitted to the front-end server 16 through the web browser, the front-end server 16 extracts the corresponding data from the DB server 14. Ask.
Then, when data is transmitted from the DB server 14, the front end server 16 processes it into a Web file and transmits it to the client terminal 12.
As a result, the user can browse data on a general-purpose Web browser displayed on the display of the client terminal 12 (see “Table List” in Non-Patent Document 2).
When the user adds or corrects data on the Web browser and an update request is sent from the client terminal 12, the front-end server 16 sends these update information to the DB server 14 to update the database. Request processing.
Sample screen of input processing [Search June 7, 2004] Internet URL: http://it.e-otsuka.com/ryutsu/images/food_sft1.gif itBASE design screen sample [Search June 7, 2004] Internet URL: http://219.118.162.84/eaccess/servlet/eAccess?PAGE=00005&acountid=access&accessid=itbase&UPAGE=00002&FILENM=pageclip&FILENO=00002&FILEID=000061&CLIPTABLE=&FORMNO= page00002 & REPORTNO

  As described above, when the database can be used via the general-purpose web browser program installed in the client terminal 12, the initial cost and running cost can be reduced compared to the case where a dedicated application program is installed in the client terminal 12. And the maintenance can be completed on the server 16 side.

By the way, as a database usage method, first, search results are sent to the client terminal as a list, and when the user selects one of the data, a detailed reference screen, correction screen, and deletion screen for the data are selected. Are generally generated and transmitted to the client terminal. When the user selects new registration in the database, a new registration screen is generated and transmitted to the client terminal.
In this way, in order to send individual screens to the client terminal when the user takes action to request a transition to a specific detail screen for the list data, a template dedicated to each detail screen is originally developed in advance. However, since there are many common parts in the configuration of each screen, the inefficiency of separately preparing screen generation templates has been recognized.
Therefore, one least common multiple basic template with all the parts to be displayed on each screen is prepared, and the display / non-display of each part is switched or activated according to the screen transition request from the client terminal. A method of realizing each detail screen by switching between / inactivation has been devised.
As a result, a single basic template can cope with a plurality of screen transitions, and there is an advantage that template management and maintenance efficiency can be improved.

However, in this method, it is necessary for the server side to determine display / non-display and activation / deactivation of each component in accordance with the request content from the client terminal 12 (the type of transition destination screen), and a control program for that purpose Need to be coded in advance (usually complex code using if and while statements).
For this reason, there is a risk of artificial bugs as well as coding work.
Further, when a change occurs in the screen design, it is necessary to make a correction to the control program in accordance with the correction of the code related to the design.

  The present invention has been devised to solve the above-described problems, and the object of the present invention is to use the basic template having the least common multiple part configuration of each detail screen while using the basic template. It is an object of the present invention to provide a database utilization technique that enables each detail screen to be displayed on a display of a client terminal without human coding in advance a control logic for generating each detail screen from a template.

In order to achieve the above object, a database utilization system according to claim 1 is a database utilization system comprising a front-end server connected to a database server and a client terminal connected to the front-end server. The front end server takes out the data list from the storage means for storing the data list transmitted from the database server, the template for generating the list screen of the data list, and the storage means, and fills the template with it. performing means for generating a Web file for the list screen display, and means for transmitting the Web file to the client terminal, the detail screen for referring to the details of the specific data included in the data list, the modification of certain data Detailed screen for deleting specific data A basic template with screen components required to form at least two detail screens in a detail screen for adding a new screen to the data list and a specific detail from the client terminal When a screen transition request to the screen is sent, refer to the setting information that specifies display / non-display or activation / deactivation of each part for each detail screen, and display or activate on the detail screen of the transition destination It means for generating a defined code that will identify the unwanted components, in the basic template, and this definition code, I follow the said defined code the ability to hide or deactivate the screen components of the base template raw each detail screen common generic control code, and optionally by filling the stored data in said storage means Web files for details screen display having Means for means for transmitting the Web file to the client terminal, said client terminal, and means for displaying a list screen based on the Web file for been list screen displayed transmitted from the front-end server to the display, this If the option of obtaining a transition to specific details screen displayed in the list screen is selected via the input means, means for requesting the distribution of the corresponding detail screen to the front-end server, the front-end In accordance with the definition code and general-purpose control code included in the Web file for displaying the detailed screen sent from the server, the detailed screen in which the parts that do not need to be displayed or activated in the basic template are hidden or deactivated is displayed on the display. It is characterized by having means for displaying.

The database utilization system according to claim 2 is a database utilization system comprising a front-end server connected to a database server and a client terminal connected to the front-end server. , Storage means for storing the data list transmitted from the database server, a template for generating a list screen of the data list, a Web for taking out the data list from the storage means, filling the template into the template, and displaying the list screen means for generating a file, and means for transmitting the Web file to the client terminal, the detail screen for referring to the details of the specific data included in the data list, detail screen for correcting the specific data, specific Detailed screen for deleting data and new data Basic template with screen components required to form at least two detail screens in the detail screen for adding data to the data list, and screen transition from client terminal to specific detail screen When a request is sent, refer to the setting information that defines the display / non-display or activation / deactivation of each part for each detail screen, and select the parts that do not need to be displayed or activated on the transition detail screen. It means for generating a defined code specifying, in the base template, and means for generating the definition code, and optionally by filling the stored data in said storage means Web files for details screen display, this comprises means for transmitting the Web files to the client terminal, said client terminal, sent from the front-end server in advance, in the definition code List based on the basic template and the detail screen common generic control code the screen components including the hide or function to deactivate the, Web files for list screen display sent from the front-end server I means for displaying a screen on the display, when the option of obtaining a transition to specific details screen displayed in this list screen is selected via the input means, the corresponding detail screen to the front end server Hiding parts that do not need to be displayed or activated in the basic template in accordance with the means for requesting distribution, the definition code contained in the Web file for detailed screen display sent from the front-end server and the general-purpose control code Alternatively, it is characterized in that there is provided means for displaying a deactivated detail screen on the display.

In the database utilization system according to claim 1, a code for defining a part unnecessary for realizing a detailed screen requested from a client terminal in a screen component included in a basic template and an interpretation of the definition code Since the code that controls the state (hidden or deactivated) of a specific part is sent to the client terminal as part of the Web file, each detail screen has a least common multiple configuration. It is possible to display an individual detail screen on the client terminal side while using the template.
Moreover, since the above definition code is automatically generated when a detailed screen delivery request is received from the client terminal, there is no risk of human bugs.
Even if the screen design changes, it is only necessary to modify the setting information that defines the correspondence between each part and state for each detailed screen, and it is necessary to modify the server-side control program as before. There is no.
Since the code for interpreting the definition code and controlling the state of the component is versatile, if it is coded in advance, it can be reused any number of times and is not affected by changes in the screen design.

In the database utilization system according to claim 2, a code defining a part unnecessary for realizing the detailed screen requested from the client terminal among the screen components included in the basic template is included as a part of the Web file. Since it is a method sent to the client terminal, each client has a least common multiple configuration for each detail screen by providing a function to control the state of unnecessary parts by interpreting this definition code on the client terminal side. It is possible to display an individual detail screen on the client terminal side while using the basic template.
In addition, since this definition code is automatically generated when a detailed screen distribution request is received from a client terminal, there is no risk of human bugs.
Even if the screen design changes, it is only necessary to modify the setting information that defines the correspondence between each part and state for each detailed screen, and it is necessary to modify the server-side control program as before. There is no.

FIG. 1 is a conceptual diagram showing the overall configuration of a database utilization system 10 according to the present invention, and a front-end server 16 having a Web server function and an AP server function between a large number of client terminals 12 and a DB server 14. Is arranged.
Each client terminal 12 and the front-end server 16 are connected via a communication network 18 such as the Internet or an intranet.
The front-end server 16 and the DB server 14 are also network-connected via a LAN.
Each client terminal 12 is set up with a general-purpose web browser program.

FIG. 2 is a block diagram showing functional configurations of the client terminal 12 and the front-end server 16.
First, the client terminal 12 includes a computer such as a PC to which an input device 20 such as a mouse and a keyboard and a display 22 are connected, and includes a processing request unit 24 and a Web page display unit 26.
Here, the processing request unit 24 is realized by the CPU of the client terminal 12 executing necessary processing according to the OS and a general-purpose Web browser program. The Web page display unit 26 is realized by the CPU of the client terminal 12 executing necessary processing according to the control code described in the OS, the Web browser program, and JavaScript. The control code written in JavaScript is distributed in advance from the front-end server 16 to the client terminal 12 (details will be described later).

The front-end server 16 includes a control unit 30, a web file generation unit 32, a business processing unit 36, a code generation unit 37, a first cache 38, a second cache 40, a buffer 42, and code storage. Part 44 is provided.
Although details will be described later, when the user accesses the front-end server 16 from the client terminal 12 and selects one database from the service menu displayed on the Web browser, the server 16 side uses the database. The dedicated application program X1 is activated, and the CPU of the server 16 executes necessary processing in accordance with this, whereby the control unit 30, the web file generation unit 32, the business processing unit 36, and the code generation unit 37 are realized.
When the user selects another database, other application programs X2, X3,... Are started separately, and the control unit 30, the web file generation unit 32, and the business processing unit 36 optimized for the database. Therefore, the code generation unit 37 appears in parallel.
The first cache 38, the second cache 40, the buffer 42, and the code storage unit 44 are set in the memory space of the front-end server 16 by the application program.
The above application program is described in, for example, Java (registered trademark) which is one of object-oriented languages.

The processing procedure when using the database using this system 10 will be described below with reference to the flowcharts of FIGS.
First, when the user accesses the front-end server 16 from the client terminal 12 and clears the authentication step that involves inputting the ID and password, the server 16 transmits a Web file (Html file or the like) for menu display (FIG. 3). (S10) A database menu screen (not shown) available to the user is displayed on the Web browser (S11).

When the user selects one database usage service from this menu, for example, “Store Master”, the processing request unit 24 of the client terminal 12 sends an initial screen distribution request to the front-end server 16 to use the database. Is transmitted (S12).
In response to this, in the front-end server 16, the application program X1 corresponding to the database is started (S13), and a dedicated control unit 30, Web file generation unit 32, business processing unit 36, and code generation unit 37 are formed. At the same time, a first cache 38, a second cache 40, and a buffer 42 are set in the memory space.

Next, an initial screen Web file of the store master is generated by the Web file generation unit 32 and transmitted to the client terminal 12 (S14).
As a result, as shown in FIG. 7, an initial screen 50 of the store master use service is displayed on the display of the client terminal 12 (S15).
On the other hand, when the user inputs a specific store code range (for example, 001 to 050) in the store code input field 52 and clicks the search button 54, the processing request unit 24 sends the corresponding store code to the front-end server 16. A search request for is sent (S16).

Receiving this, the control unit 30 of the front end server 16 sets the range of the store code in the buffer 42 as a search condition (S17).
The business processing unit 36 transmits this search condition to the DB server 14 and requests extraction of the corresponding record (S18).
On the other hand, the DB server 14 extracts a record that matches the search condition from the database of the store master and transmits it to the business processing unit 36.
The business processing unit 36 stores these data lists received from the DB server 14 in the buffer 42 (S19).

In contrast, the control unit 30 temporarily stores the data list stored in the buffer 42 in the first cache 38 (S20).
Next, the control unit 30 refers to the line number information (1 page = 10 lines) of the list set in advance in the program code based on the screen design, and stores the store master data stored in the first cache 38. 10 items are extracted from the top of the list and stored in the second cache 40 (S21).

The Web file generation unit 32 extracts 10 data lists from the second cache 40, embeds them in a search result display template, generates a Web file, and transmits it to the client terminal 12 (S22).
As a result, as shown in FIG. 8, a search result list screen 58 including a list 56 for displaying each data of the store codes = 001 to 010 as one line is displayed on the display 22 of the client terminal 12 (S23).
In this list 56, the store code, store kanji name, supplier code, supplier kanji name, opening date, and closing date data items are displayed for each store.
Each record of the store master actually includes other data items, but only the data items required by the control unit 30 when data is transferred from the first cache 38 to the second cache 40. As a result of the extraction, only the above-described data items are displayed in the list 56.

  As described above, only 10 data lists are copied from the first cache 38 to the second cache 40 by the control unit 30, and the Web file generation unit 32 generates Web files for list display in units of 10 items. Since this is transmitted to the client terminal 12, the list 56 is fixed to 10 lines per page.

Although illustration is omitted, when the user clicks the next page scroll button 60 in the list 56, a delivery request for the next page screen is transmitted from the client terminal 12 to the front-end server 16.
Receiving this, the control unit 30 of the front-end server 16 takes out the next 10 data lists to be displayed on the next page from the first cache 38 and stores them in the second cache 40.
On the other hand, the Web file generation unit 32 extracts 10 records from the second cache 40, embeds them in the template, generates a Web file, and transmits it to the client terminal 12.
As a result, the display 22 of the client terminal 12 displays a search result list screen having a list that displays each line of the store codes = 011 to 020 as one line.

When the user clicks on specific data from the list 56 in FIG. 8 to select it and clicks the reference button 62 as it is, the processing request unit 24 of the client terminal 12 sends the data to the front-end server 16. A reference screen distribution request for browsing the detailed information is transmitted (S24). In FIG. 8, the Mitakadai store with the store code = 007 is selected.
Receiving this, the control unit 30 copies the Mitakadai store record from the first cache 38 to the second cache 40 (S25), and instructs the code generation unit 37 to generate a definition code for the reference screen. To do.

  On the other hand, the code generation unit 37 refers to the setting information described in advance in the program code based on the screen design, and automatically generates the definition code for the reference screen according to the JavaScript grammar (S26 in FIG. 4).

That is, in this store master use service, a basic detail screen 64 shown in FIG. 9 is designed in advance.
The basic detail screen 64 is a least common multiple screen including all the components (buttons, fields, etc.) of various detail screens developed from the store master list 56 as a starting point. It is a mechanism in which individual detail screens are realized by hiding or deactivating components.
Here, “non-display” literally means that buttons and the like are hidden and not displayed on the screen. “Deactivation” means that the button or field is displayed but cannot be clicked or entered.
An identification code is assigned to each component of the basic detail screen 64, and each identification code and state (separate display / non-display / active / inactive) are included in the program code that implements the code generation unit 37. Are set for each detail screen.

  Since the request from the client terminal 12 this time is a transition to the reference screen, the code generation unit 37 designates the registration button 66 and the delete button 68 that are not necessary on the reference screen as non-display compatible, and the opening date and closing date Generate a definition code that specifies that the pull-down button 70 provided in the input field such as date is not displayed, and specifies all data items in the inactive (non-inputable) field, and stores it in the second cache 40 To do.

  On the other hand, the Web file generation unit 32 generates a reference screen Web file by fetching one record and definition code from the second cache 40 and filling them in the above-mentioned basic screen generation template. The data is transmitted to the client terminal 12 (S27).

Receiving this, the Web page display unit 26 of the client terminal 12 displays the reference screen 72 of the Mitakadai store on the display 22 as shown in FIG. 10 (S28).
At this time, the web page display unit 26 interprets the above definition code and treats unnecessary parts as non-display and treats all data items as non-inputable fields. As a result, the reference screen 72 includes the basic detail screen 64. The registration button 66, the delete button 68, and the pull-down button 70 are hidden. In addition, all data items are non-inputable fields that can only be displayed and cannot be input.

When the user clicks the return button 74 here, a request for redisplay of the list screen is transmitted from the client terminal 12 to the front end server 16 (S29).
In the front end server 16 that has received this, the control unit 30 copies the data list for the ten items from the top to the second cache 40 from the first cache 38 (S30).
The Web file generation unit 32 fills these data lists into a search result display template to generate a Web file, and transmits it to the client terminal (S31).
As a result, the list screen 58 of FIG. 8 is displayed again on the display 22 of the client terminal 12 (S32).

Next, when the user clicks other data (for example, store code: 008 Kokubunji store) to select it, and clicks the correction button 76 as it is, the processing request unit 24 of the client terminal 12 sends the front end server 12 to the front end server 12. A distribution request for the correction screen of the data is transmitted (S33).
Receiving this, the control unit 30 copies the record of the Kokubunji store from the first cache 38 to the second cache 40 (S34) and instructs the code generation unit 37 to generate a definition code for the correction screen. To do.

On the other hand, the code generation unit 37 automatically generates the definition code (JavaScript) for the correction screen with reference to the setting information described in the program code (S35) and stores it in the second cache 40.
Since the request from the client terminal 12 this time is a transition to the correction screen, the code generation unit 37 generates a definition code that specifies that the delete button 68 that is not required to be displayed is hidden on the correction screen.
On the other hand, the registration button 66 and the pull-down button 70 provided in the date input field are required on the correction screen, and therefore the basic detail screen 64 remains. Each data item is also left as an inputable field.

  The Web file generation unit 32 takes out one record and definition code from the second cache 40, fills them with the basic screen generation template described above, generates a modified screen Web file, and the client terminal 12 is transmitted (S36).

Receiving this, the Web page display unit 26 of the client terminal 12 displays the correction screen 78 of the Kokubunji store on the display 22, as shown in FIG. 11 (S37).
At this time, as a result of the Web page display unit 26 interpreting the definition code and treating the unnecessary delete button 68 as non-display, the delete button 68 is not displayed on the correction screen 78. On the other hand, the registration button 66 and the pull-down button 70 are displayed as they are, and all the data items are data inputable fields in which data can be input / corrected.

On the other hand, when the user completes new input or correction input of necessary data items (S38) and clicks the registration button 66, the client terminal 12 sends a correction data registration request to the front-end server 16. (S39).
Receiving this, the control unit 30 of the front-end server 16 overwrites the corresponding record in the first cache 38 with the data transmitted from the client terminal 12, and reflects the correction on the client terminal 12 (S40).

Next, when the user clicks the return button 74, a request for redisplay of the list screen is transmitted from the client terminal 12 to the front-end server 16 (S41 in FIG. 5).
In the front end server 16 that has received this, the data list for 10 cases is copied from the first cache 38 to the second cache 40 by the control unit 30 (S42).
The Web file generation unit 32 fills these data lists into a search result display template to generate a Web file, and transmits it to the client terminal 12 (S43).
As a result, the list screen 58 of FIG. 8 is displayed again on the display 22 of the client terminal 12 (S44).

Next, when the user clicks another record (for example, Nomidai store with store code: 009) to select it and clicks the delete button 80, the processing request unit 24 of the client terminal 12 sends the front end server 12 A delete screen distribution request relating to the store is transmitted (S45).
Receiving this, the control unit 30 copies the record of the Nomidai store from the first cache 38 to the second cache 40 (S46), and instructs the code generation unit 37 to generate a definition code for the deletion screen. To do.

On the other hand, the code generation unit 37 automatically generates a deletion screen definition code (JavaScript) with reference to the setting information described in the program code (S47) and stores it in the second cache 40.
Since the request from the client terminal 12 this time is a transition to the deletion screen, the code generation unit 37 hides the registration button 66 and the pull-down button 70 that are not required to be displayed on the deletion screen, and cannot input all data items. Generate a definition code to be specified in the field.

  The Web file generation unit 32 extracts a record and definition code for one record from the second cache 40, fills the basic screen generation template with these records, generates a deletion screen Web file, and generates a client terminal. 12 is transmitted (S48).

Receiving this, the Web page display unit 26 of the client terminal 12 displays the delete screen 82 of the Nomidai store on the display 22 as shown in FIG. 12 (S49).
At this time, as a result of the Web page display unit 26 interpreting the definition code and treating the unnecessary registration button 66 and pull-down button 70 as hidden, the registration button 66 and the pull-down button 70 are displayed on the deletion screen 82. Absent. In addition, all data items are non-inputable fields that can only be displayed and cannot be input.

On the other hand, when the user confirms the contents of each data item and clicks the delete button 68, the client terminal 12 transmits a request to delete the corresponding record to the front-end server 16 (S50).
Receiving this, the control unit 30 of the front-end server 16 deletes the record requested to be deleted from the client terminal 12 from the data list in the first cache 38 (S51).

Next, when the user clicks the return button 74, a request for redisplay of the list screen is transmitted from the client terminal 12 to the front end server 16 (S52).
In the front-end server 16 that has received this, the data list for 10 cases is copied from the first cache 38 to the second cache 40 by the control unit 30 (S53).
The Web file generation unit 32 fills these data lists into a search result display template to generate a Web file, and transmits it to the client terminal (S54).
As a result, the list screen 58 of FIG. 8 is displayed again on the display 22 of the client terminal 12 (S55).

Here, when the user clicks the new button 84, a distribution request for a new record registration screen is transmitted from the processing request unit 24 of the client terminal 12 to the front-end server 16 (S56 in FIG. 6).
Receiving this, the control unit 30 instructs the code generation unit 37 to generate a definition code for a new registration screen.

On the other hand, the code generation unit 37 refers to the setting information described in the program code, automatically generates a definition code (JavaScript) for a new registration screen (S57), and stores it in the second cache 40.
Since the request from the client terminal 12 this time is a transition to the new registration screen, the code generation unit 37 generates a definition code that specifies that the delete button 68 that is not required to be displayed is hidden on the new registration screen.
In contrast, the registration button 66 and the pull-down button 70 are displayed as they are because they are required on the new registration screen. Each data item is left as an inputable field.

  The Web file generation unit 32 takes out the definition code from the second cache 40, fills the basic screen generation template with the definition code, generates a new registration screen Web file, and transmits it to the client terminal 12 ( S58).

Receiving this, the Web page display unit 26 of the client terminal 12 displays a new registration screen 86 on the display 22 as shown in FIG. 13 (S59).
At this time, as a result of the Web page display unit 26 interpreting the definition code and treating the unnecessary delete button 68 as non-display, the delete button 68 is not displayed on the new registration screen 86. On the other hand, the registration button 66 and the pull-down button 70 are displayed as they are and are data inputable fields in which data can be input / corrected for all data items.

On the other hand, when the user completes new data entry in the necessary data items (S60) and clicks the registration button 66, a new registration request for input data is transmitted from the client terminal 12 to the front-end server 16 (S61). ).
Receiving this, the control unit 30 of the front-end server 16 adds the data transmitted from the client terminal 12 to the data list of the first cache 38 (S62).

Next, when the user clicks the return button 74, a request for redisplay of the list screen is transmitted from the client terminal 12 to the front end server 16 (S63).
In the front end server 16 that receives this, the control unit 30 copies the data list for 10 cases from the first cache 38 to the second cache 40 (S64).
The Web file generation unit 32 fills these data lists into a search result display template to generate a Web file, and transmits it to the client terminal (S65).
As a result, the list screen 58 of FIG. 8 is displayed again on the display 22 of the client terminal 12 (S66).

Finally, when the user clicks the end button 88, an end request is transmitted from the client terminal 12 to the front-end server 16 (S67).
Receiving this, the control unit 30 of the front-end server 16 sets the data list stored in the first cache 38 in the buffer 42 (S68).

The business processing unit 36 transmits the data list in the buffer 42 to the DB server 14 and requests a record update (S69).
Receiving this, the DB server 14 updates the store master database with the data list received from the business processing unit 36.

Although not shown in the flowchart, the definition code for each transition screen generated by the code generation unit 37 is cached in the code storage unit 44 each time.
When a display request for a detailed screen is transmitted in this store master use service, the code generation unit 37 first checks the code storage unit 44. If the target definition code exists, a new definition code is added. The existing definition code is stored in the second cache 40 without being generated.

The JavaScript definition code generated by the code generation unit 37 is a code that designates the state (display / non-display or activation / deactivation) for each part constituting the basic detail screen 64, JavaScript for executing the process of interpreting this and realizing the state of a specific component is distributed in advance to each client terminal 12 as a .js (dot jay) file.
Since the control code itself that interprets the definition code sent from the front-end server 16 is common to each detail screen, it is efficient to distribute it to the client terminal 12 in advance as a .js file in this way. It can be said that it also contributes to the reduction of

However, the present invention is not limited to this, and after the definition code is generated in the code generation unit 37 of the front-end server 16, the Web file generation unit 32 and the definition code stored in the second cache 40 A control code for interpreting the above may be embedded in the Web file and distributed to the client terminal 12.
As a result, in the client terminal 12, the control code is incorporated into a part of the web page display unit 26, and the component that does not need to be displayed or activated is identified by interpreting the definition code. To hide or inactivate.

In the case of this system 10, when the transition is made from the list screen to the detail screen as described above, the code generation unit 37 automatically generates a definition code that defines the state of each detail screen constituting the basic detail screen. Is generated and inserted into the basic template by the Web file generator 32 to generate a Web file for each detail screen. The Web page display unit 26 of the client terminal 12 displays / hides each component according to the above definition code. Alternatively, a specific detailed screen is formed by switching between activation / deactivation.
As a result, even if it is necessary to make changes to the screen design, the designer only needs to modify the code of the part related to the design in the basic template, and even the logic to control the state of each part related to it. There is no need to make corrections.
Moreover, since the definition code is generated by the code generation unit 37, there is no room for artificial bugs.

It is a conceptual diagram which shows the whole structure of the database utilization system which concerns on this invention. It is a block diagram which shows the function structure of a client terminal and a front end server. It is a flowchart which shows the process sequence in this system. It is a flowchart which shows the process sequence in this system. It is a flowchart which shows the process sequence in this system. It is a flowchart which shows the process sequence in this system. It is a layout figure which shows the initial screen of a store master utilization service. It is a layout figure which shows the search result list screen of a store master utilization service. It is a layout figure which shows the basic screen of a store master utilization service. It is a layout figure which shows the reference screen of shop master utilization service. It is a layout figure which shows the correction screen of a store master utilization service. It is a layout figure which shows the deletion screen of a store master utilization service. It is a layout figure which shows the new registration screen of a store master utilization service.

10 Database usage system
12 Client terminal
14 DB server
16 Front-end server
18 Communication network
20 Input device
22 display
24 Processing request section
26 Web page display area
30 Control unit
32 Web file generator
36 Business Processing Department
37 Code generator
38 First cache
40 Second cache
42 buffers
44 Code storage
50 Store master use service initial screen
52 Store code input field
54 Search button
56 List
58 List screen
58 Search result list screen
60 Next page scroll button
62 Browse button
64 Basic details screen
66 Registration button
68 Delete button
70 Pull-down button
72 Reference screen
74 Back button
76 Modify button
78 Modification screen
80 Delete button
82 Delete screen
84 New button
86 New registration screen
88 Exit button
X1, X2, X3 application program

Claims (2)

A database utilization system comprising a front-end server connected to a database server and a client terminal connected to the front-end server,
The front-end server
Storage means for storing a data list transmitted from the database server;
A template for generating the list screen of the data list,
Retrieve data list from said memory means, means for generating a Web file for the list screen displays it by filling in the template,
Means for sending this web file to the client terminal;
A detailed screen for referring to detailed information of specific data included in the data list, a detailed screen for correcting specific data, a detailed screen for deleting specific data, and new data are added to the data list. A basic template with screen components required to form at least two detail screens among the detail screens for
When a screen transition request to a specific detail screen is sent from the client terminal, refer to the setting information that specifies the display / non-display or activation / deactivation of each component for each detail screen, and the details of the transition destination Means for generating a definition code for identifying a part that does not need to be displayed or activated on the screen;
In the basic template, and this definition code, the detail screen common generic control code with the ability to hide or deactivate the screen components of the basic template I follow the said definition code, and optionally means for generating a Web file for detail screen display by filling the stored data in said storage means,
It has means to send this web file to the client terminal,
The client terminal
Means for causing a display to display a list screen based on the list screen display Web file transmitted from the front-end server;
If the option of obtaining the transition to this list specific details screen displayed in the screen is selected via the input means, means for requesting the distribution of the corresponding detail screen to the front-end server,
Detail screen that hides or deactivates parts that do not need to be displayed or activated in the basic template according to the definition code and general-purpose control code included in the Web file for displaying the detail screen sent from the front-end server. A database utilization system comprising means for displaying a message on a display. A database utilization system comprising a front-end server connected to a database server and a client terminal connected to the front-end server,
The front-end server
Storage means for storing a data list transmitted from the database server;
A template for generating the list screen of the data list,
Retrieve data list from said memory means, means for generating a Web file for the list screen displays it by filling in the template,
Means for sending this web file to the client terminal;
A detailed screen for referring to detailed information of specific data included in the data list, a detailed screen for correcting specific data, a detailed screen for deleting specific data, and new data are added to the data list. A basic template with screen components required to form at least two detail screens among the detail screens for
When a screen transition request to a specific detail screen is sent from the client terminal, refer to the setting information that specifies the display / non-display or activation / deactivation of each component for each detail screen, and the details of the transition destination Means for generating a definition code for identifying a part that does not need to be displayed or activated on the screen;
In the basic template, it means for generating the definition code, and optionally by filling the stored data in said storage means Web files for detail screen display,
It has means to send this web file to the client terminal,
The client terminal
General control code common to each detail screen, which has a function to hide or deactivate the screen component of the basic template according to the definition code sent in advance from the front-end server,
Means for causing a display to display a list screen based on the list screen display Web file transmitted from the front-end server;
If the option of obtaining the transition to this list specific details screen displayed in the screen is selected via the input means, means for requesting the distribution of the corresponding detail screen to the front-end server,
Details in which parts that do not need to be displayed or activated in the basic template are hidden or deactivated according to the definition code contained in the Web file for detailed screen display sent from the front-end server and the general-purpose control code. A database utilization system comprising means for displaying a screen on a display.

Images