Information processing device, information processing method, and program

Abstract

An information processing device, an information processing method, and a program are provided that can easily generate application software that mixes screens that can be directly transitioned and screens that cannot be directly transitioned. [Solution] The method displays a display item that accepts an instruction as to whether or not to assign identification information to a screen displayed by application software to be generated. The application software responding to the instruction on the display item generates specific application software capable of displaying a first screen for which an instruction to assign identification information with the display item has been accepted and a second screen for which no instruction to assign identification information has been accepted. When the specific application software is executed, identification information for the first screen that instructs the display of the first screen is output to the user, but identification information for the second screen that instructs the display of the second screen is not output to the user.

Description

Technical Field

[0005] ,

[0004] , , , , , , ,

[0006]

[0001] The present invention relates to an information processing apparatus, an information processing method, and a program for generating application software.

Background Art

[0002] Recently, single-page applications (SPAs) that can return fast responses to users and provide excellent UI / UX have been utilized. A single-page application is characterized in that it realizes screen drawing while dynamically changing a single HTML page with JavaScript, and only the first time the entire page is loaded, and from the second time onwards, only the necessary parts are reloaded by receiving JSON data from the server. Since there is no need to generate a screen on the server side, a system in which application software can operate with a minimum of data transfer can be formed, reducing the waiting time on the user side and leading to user satisfaction.

[0003] By the way, even if the UI transitions from the page initially sent to the client to the next page in a single-page application, since it is a single page, there is a problem that the URI remains the same and all screens have the same URI.

[0004] Therefore, it is impossible to bookmark any screen after the transition of a single-page application, and in order to display the target screen, it is necessary to always follow the same transition from the initial display screen.

[0005] In order to solve the above problem, there is a technique called routing in a single-page application to set an arbitrary URI for each screen.

[0006] Patent Document 1 describes an invention that solves the problem that the development of a single-page application becomes difficult when the transition relationships between various screens for using a web application are complicated.

Prior Art Documents

[0007] [Patent Document 1] Japanese Patent Publication No. 2017-220221 [Overview of the Initiative] [Problems that the invention aims to solve]

[0008] However, for developers creating single-page applications, if routing technology associates a URI with every UI element they transition to, it becomes inconvenient if there are UI elements (screens) that they do not want the application software user to transition to directly via URI.

[0009] For example, in the case of application software that transitions between screens such as an input screen → a confirmation screen of the input content → a screen for selecting the applicant (approver), we do not want the application software user to be able to directly navigate to the confirmation screen via URI or bookmark it.

[0010] With routing-based mapping of arbitrary URIs, creating a single-page application that mixes screens that can be accessed directly via such URIs with screens that cannot be accessed directly required complex routing configurations, making it a difficult task for developers.

[0011] The objective of the present invention is to provide a mechanism for easily generating application software that mixes screens that can be directly accessed with screens that cannot be directly accessed. [Means for solving the problem]

[0012] To solve the above problems, an information processing system according to one embodiment of the present invention includes a display control means that controls the display of a display item that accepts an instruction on whether or not to assign identification information to a screen displayed by the generated application software, and a control means that controls the generation of application software in response to the instruction received for the display item, wherein the specific application software is capable of displaying a first screen in which an instruction to assign identification information has been received by the display item, and a second screen in which an instruction to assign identification information has not been received by the display item, and the specific application software is capable of generating such specific application software which, when the specific application software is executed, outputs identification information for the first screen to instruct the display of the first screen to the user of the specific application software, and does not output identification information for the second screen to the user to instruct the display of the second screen. [Effects of the Invention]

[0013] The present invention provides a mechanism that facilitates the development of applications that can switch and display screens using identification information to uniquely identify a single resource. [Brief explanation of the drawing]

[0014] [Figure 1] This is a system configuration diagram of this embodiment. [Figure 2] This is a hardware block diagram of the program development device, execution server, database server, and client PC of this embodiment. [Figure 3] This is a functional block diagram of the software for the program development device of this embodiment. [Figure 4] This is a functional configuration diagram of the system in this embodiment. [Figure 5] This is a flowchart of the web application generation process in this embodiment. [Figure 6]This is a flowchart of the routing setting process according to the present embodiment. [Figure 7] This is an example of a screen display shown on the output unit 210 according to the present embodiment. [Figure 8] This is an example of a screen display shown on the output unit 210 according to the present embodiment. [Figure 9] This is an example of a routing setting file according to the present embodiment. [Figure 10] This is an example of a screen display shown on the output unit 210 according to the present embodiment.

Mode for Carrying Out the Invention

[0015] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0016] FIG. 1 is a configuration diagram of a system (information processing system) showing an example of the configuration of a program development apparatus (an information processing apparatus used by a developer for Web application generation), a program development server, a database server, a client PC (client device), an execution server, and a Web server according to the present invention.

[0017] The program development apparatus 101 defines a screen layout, a database search instruction, etc. according to the operation of the developer. Note that in the program development apparatus 101, the role may be divided such that the developer's input is received and the actual program generation process and application generation process (generation process of application software) are performed on the program development server 102 described later, or the program development apparatus 101 may perform the program generation and application software generation by itself.

[0018] In this embodiment, the application software generated by the program development apparatus 101 is a Web application, but it is not limited thereto, and it may not be application software using communication based on Web technology, such as application software operating on an information processing apparatus such as a mobile phone, smartphone, tablet, or embedded software.

[0019] Also, in this embodiment, although the program development device 101 generates the program of the application software, it is not limited to the generation of the program, and the environment in which the application software operates may be constructed using the definitions set according to the operations of the developer.

[0020] The program development servers 102a to 102b (information processing devices) generate a program according to the settings and instructions of the developer input by the program development device 101. The program development server 102a may be arranged in a network 107 such as a LAN, and the program development server 102b may be arranged on the Internet or in the cloud.

[0021] The database servers 103a to 103b (information processing devices) are databases used by the developed application software, and may also be used for operation confirmation and the like during development in the present invention. For example, the database server 103 for the developer to use may be configured by the same device as the program development device 101, or may be arranged in a network 107 such as a LAN (database server 103a). It may also be arranged on the Internet or in the cloud (database server 103b). Also, when the program development device 101 cooperates with the program development server 102, the program development server 102 and the database server 103 may be configured in the same device.

[0022] The execution server 105 (information processing device) executes the application program generated by the program development device 101 (the program of the application software generated by the program development device 101). The execution server 105 may be arranged in a network 107 such as a LAN (execution server 105a), or may also be arranged on the Internet or in the cloud (execution server 105b). Also, it can operate by connecting to the database server 103 on the network 107, the Internet, or the cloud.

[0023] Client PCs 104a to 104b (information processing devices) are user input terminals that operate application programs developed on the program development device 101 in cooperation with the execution server 105. They may be located within a network 107 such as a LAN (client PC 104a), or they may be located on the internet or in the cloud (client PC 104b). They may also be information processing devices such as mobile terminals.

[0024] Figure 2 is a block diagram showing an example of hardware configurations applicable to the program development device 101, execution server 105, database server 103, and client PC 104 according to the present invention.

[0025] In Figure 2, CPU 201 is at least one processor that centrally controls each device connected to the system bus 204.

[0026] Furthermore, the ROM 203 or external memory 211 stores the operating system (OS), which is the control program for the CPU 201, as well as programs for realizing various functions of the information processing devices, such as servers, clients, and other devices, as described later.

[0027] RAM202 functions as the main memory, work area, and temporary storage area for CPU201.

[0028] The input controller 205 controls the input from the input unit 209. In an information processing device, the input unit 209 may include a keyboard, a pointing device such as a mouse, or a touch panel.

[0029] Furthermore, if the input unit 209 is a touch panel, the user can give various instructions by pressing (touching with a finger, etc.) the icons, cursors, or buttons displayed on the touch panel.

[0030] Furthermore, the touch panel may be a multi-touch screen or other touch panel capable of detecting the positions of multiple fingers touching it.

[0031] The output controller 206 controls the display of the output unit 210. Examples of the output unit 210 include CRTs and liquid crystal displays. It also includes the display of a notebook computer integrated with the main unit. Furthermore, a projector may also be used.

[0032] The external memory controller 207 controls access to the external memory 211, which stores boot programs, various application software, font data, user files, editing files, printer drivers, etc. The external memory 211 stores various tables and parameters for realizing various functions of each server, client, device, etc. Examples of this external memory 211 include hard disks (HDs), flexible disks (FDs), CompactFlash® cards connected to PCMCIA card slots via adapters, SmartMedia, etc.

[0033] The CPU 201 enables display on the output unit 210 by, for example, performing outline font expansion (rasterization) processing in the display information area of ​​RAM 202. The CPU 201 also enables developer instructions via a mouse cursor (not shown) on the output unit 210.

[0034] The communication interface controller 208 performs communication control processing with external devices via the network. For example, it can perform communication using TCP / IP.

[0035] The program 212 for realizing the present invention is stored in external memory 211 and is executed by the CPU 201 when loaded into RAM 202 as needed.

[0036] Figure 3 is an example of a block diagram showing the software configuration of an embodiment of the present invention.

[0037] The program development device 101 includes the following functional units.

[0038] The definition unit 301 is a functional unit that receives screen definition information from the developer, such as the arrangement of screens and items (input / output items) displayed by the application software, and screen transition definition information that defines the procedure for the application software's screen to transition to the next screen.

[0039] The first configuration unit 302 is a functional unit that receives input from the user regarding whether to add a screen code that identifies a screen within the screen definition information as the destination URI for a single-page application. A single-page application has a routing library that renders (associates, links) the page destination URI with the screen, and when a screen code is added as the destination URI in the first configuration unit 302, the received UI screen can display a screen that is directly rendered using the URI set in the second configuration unit.

[0040] In this invention, the location of a single-page application is specified by a URI, but any identification information that uniquely identifies a resource is acceptable, rather than a URI. Furthermore, although this invention describes a single-page application, it does not necessarily have to be a single-page application; any application software that can switch and display screens using a single URI is acceptable.

[0041] The second configuration unit 303 is a functional unit that assigns the screen code received by the first configuration unit to the URI of a single-page application. The screen code assigned by the second configuration unit allows URIs to be assigned to multiple UI screens that transition between screens in a single-page application, and even though it is a single-page application, it is possible to directly transition to a UI screen to which a screen code has been assigned.

[0042] The screen identification information uniqueness determination unit 304 determines whether the screen code is unique. If the screen code is not unique within the application software, it is determined to be a program generation error because there is a possibility of URI overlap.

[0043] Figure 4 is a diagram showing the configuration of the program development device 101, the execution server 105, and the client PC 104.

[0044] The program development device 101 includes a repository definition unit 400 and a web application generation unit 410.

[0045] Execution server 105 corresponds to execution server 420 in Figure 4, and client PC 104 corresponds to client PC 440.

[0046] The program development device 101 generates compiled Java® code 421 and source code 422 such as HTML / JSP / JavaScript® (including single-page applications) using the Web application generation unit 410.

[0047] The repository definition unit 400 contains application definitions 401, screen definitions 402, screen transition definitions 403, action binding definitions 404, data model definitions 405, business process definitions 406, database definitions 407, and generation setting information 408. The information in the repository definition unit 400 is stored in external memory 211.

[0048] Application definition 401 holds the overall settings for the application software developed by the developer. This definition also includes a definition of whether or not the application software should be a single-page application.

[0049] Screen definition 402 holds definition information for the layout of various items placed on the application software screen, and includes input item definition information and output item definition information. Input item definition information defines the input items that the end user of the application software inputs via the screen of the generated application software. Output item definition information defines the output items that are output to the screen of the generated application software. Hereafter, input items and output items will be collectively referred to as input / output items. It also contains information from screen transition definition 403, which defines information on transitions between screens.

[0050] Action bind definition 404 defines the management of data sources for retrieving data from external sites, as well as the method for converting the retrieved data.

[0051] Data model definition 405 holds definition information for the items in the database tables. Each input / output item in screen definition 402 can be associated with an item in data model definition 405.

[0052] Business process definition 406 holds definition information for the logic used to process data in application software.

[0053] Database definition 407 defines information related to the database to which the application software connects (such as the IP address of the database server 103, the connecting user, and the connecting password).

[0054] The generation setting information 408 either assigns the screen code obtained in the first setting unit 302 as the destination URI (generates routing settings), and if assigned, the assigned URI information is stored.

[0055] The repository definition section is one example of a means of storing the definition of the application software to be generated.

[0056] The web application generation unit 410 analyzes the repository definition unit 400 set by the developer and generates a web application (including a single-page application) that includes compiled Java® code 421 and source code 422.

[0057] The repository definition analysis unit 411 analyzes the repository definition unit 400 set by the developer.

[0058] The generation setting information analysis unit 412 obtains from the generation setting information 408 whether to add the screen code as the destination URI (to generate routing settings), and if routing settings are to be generated, it requests processing from the routing setting generation unit 415.

[0059] The routing configuration generation unit 415 consists of a routing configuration analysis unit 416 and a routing configuration output unit 417. The routing configuration generation unit 415 analyzes screen definition information from the information from the generated configuration information analysis unit 412 and the screen definition 402 in the routing configuration analysis unit 416. The routing configuration output unit 417 outputs a routing configuration file according to the analysis by the routing configuration analysis unit 416. An example of a routing configuration file will be described later in Figure 9.

[0060] The web application code generation unit 413 generates the source code of the application software using the code generation rules stored in the external memory 211, the contents analyzed by the repository definition analysis unit 411, and the generation setting information analysis unit 312.

[0061] The source code compilation unit 414 compiles the source code generated by the web application code generation unit 413 and deploys the compiled Java® code 421 and source code 422, which includes a single-page application and routing configuration files, to the execution server 420.

[0062] The execution server 420 stores the web application, including the compiled Java® code 421 and source code 422 generated by the web application generation unit 410, and starts the web application.

[0063] The client PC 440 downloads a single-page application by specifying the URI of the execution server 420 from the web browser 441, and then accepts user input in the web browser 441 and executes the generated web application.

[0064] Figure 5 shows an example of a flowchart for generating a web application. Note that each step in the flowchart below is executed by the CPU 201 of the program development device 101.

[0065] The flowchart in Figure 5 shows the processing flow initiated by the program development device 101 when a developer attempts to generate a web application after defining each definition in the repository definition unit 400. The processing of each step is described below in detail.

[0066] First, in step S501, the CPU 201 of the program development device 101 loads the application definition 401 of the repository definition unit 400, which is stored in the external memory 211, into the RAM 202.

[0067] Next, in step S502, the CPU 201 of the program development device 101 loads the data model definition 405 of the repository definition unit 400, which is stored in the external memory 211, into the RAM 202.

[0068] In step S503, the CPU 201 of the program development device 101 loads the screen definition 402 of the repository definition unit 400 stored in the external memory 211 into the RAM 202. Referring to the loaded screen definition 402, screen generation is performed in step S508. The following processes are similar.

[0069] In step S504, the CPU 201 of the program development device 101 reads the action bind definition 404 of the repository definition unit 400, which is stored in the external memory 211, into the RAM 202.

[0070] In step S505, the CPU 201 of the program development device 101 loads the business process definition 406 of the repository definition unit 400, which is stored in the external memory 211, into the RAM 202.

[0071] In step S506, the CPU 201 of the program development device 101 reads the database definition 407 of the repository definition unit 400, which is stored in the external memory 211, into the RAM 202.

[0072] In step S507, the CPU 201 of the program development device 101 generates the routing settings for the single-page application. In step S507, a routing setting file like the one shown in Figure 9 is generated. Details of step S507 will be described later with reference to Figure 6.

[0073] In step S508, the CPU 201 of the program development device 101 retrieves information from each definition and file of the repository definition unit 400 loaded into the RAM 202 and generates the source code of the application software.

[0074] The generated source code includes not only files containing programming languages, but also application software such as HTML, JSP, and JavaScript (registered trademark), the single-page application used in this invention, and routing configuration files (Figure 9) generated in step S507.

[0075] In step S509, the CPU 201 of the program development device 101 deploys the application programs generated in step S508 to the execution server 105. This allows the applications to run on the execution server 105.

[0076] This concludes the explanation of the flowchart in Figure 5.

[0077] Next, the details of the process in step S507 will be explained with reference to Figure 6.

[0078] Figure 6 shows an example flowchart illustrating the routing configuration process during web application generation. Note that each step in the following flowchart is executed by CPU 201 of each device.

[0079] The flowchart in Figure 6 shows the sequence of processes that begin when the process transitions to step S507 in the flowchart in Figure 5.

[0080] First, in step S601, the CPU 201 of the program development device 101 loads the application definition 401 into the RAM 202.

[0081] Next, in step S602, the CPU 201 of the program development device 101 divides the processing based on the information of the application definition 401 acquired in step S601. If it is registered to generate the application software as a single-page application, the process transitions to step S603. If it is registered not to generate the application software as a single-page application, the process shown in the flowchart of Figure 6 is terminated.

[0082] When the process transitions to step S603, the CPU 201 of the program development device 101 loads one screen definition 402 of the application software into the RAM 202. A screen that defines part of the loaded screen definition information will be explained with reference to Figures 7 and 8.

[0083] Figures 7 and 8 show examples of screen displays shown on the output unit 210 in this embodiment. The setting screen 700 in Figure 7 and the setting screen 800 in Figure 8 are examples of setting screens that accept input from the user in advance before the flowchart in Figure 5 is implemented.

[0084] Figures 7 and 8 show examples of screens output by the output unit 210 of the program development device 101 and displayed on the display of the program development device 101. Figures 7 and 8 also show examples of setting screens that accept settings related to the application software to be generated from the developer (user of the program development device 101) during the application software development stage by the program development device 101.

[0085] Figure 10 also shows examples of screens displayed on the client PC 104's screen when the application software generated reflecting the settings in Figure 7 is executed, with the input screen 1001, confirmation screen 1002, and selection screen 1003 being the screens displayed on the client PC 104's screen. In other words, each display example in Figure 10 is a screen output to the user of the generated application software (the user of the client PC 104). Furthermore, each display example in Figure 10 is an example of a display output by the output unit 214 of the client PC 104 and displayed on the client PC 104's screen. Figure 10 shows an example of a display in application software (application software generated by the program development device 101) that allows an employee, who is the user of the client PC 104, to apply for and register their work style. On the input screen 1001, the user (employee) enters their name, gender, and work style (the input screen 1001 shows an example where "Taro Yamada", "Male", and "Working from Home" are entered), and when they click the button icon labeled "Proceed to Input Confirmation", the confirmation screen 1002 is displayed. On confirmation screen 1002, the information entered on input screen 1001 is displayed. After the user reviews the displayed information and confirms that there are no errors in the entered information, they click the button icon labeled "Proceed to Select Applicant". If there are errors in the entered information, the user uses the browser's back button to display input screen 1001 again and correct the entered information. When the button icon labeled "Proceed to Select Applicant" is clicked on confirmation screen 1002, selection screen 1003 is displayed. On selection screen 1003, the user selects the person responsible for approval (for example, their supervisor) and clicks the confirm button. When the confirm button is clicked, the selected approver is notified of the application details (the information entered on input screen 1001), and the approver can then perform the approval. This application software is designed to operate in the manner described above.

[0086] The settings screen 700 in Figure 7, displayed by selecting tab 703, corresponds to the input screen 1001 in Figure 10. The settings screen 800 in Figure 8, displayed by selecting tab 704, corresponds to the confirmation screen 1002 in Figure 10. Tab 705 is a tab that accepts instructions to display the settings screen corresponding to the selection screen 1003 in Figure 10. In each settings screen, it is possible to set whether or not to present (output) the URI of the corresponding screen among the screens to be displayed by the application software to be generated to the user of the client PC 104.

[0087] Tabs 703 to 705 are tabs for each screen of the respective application software. Tab 703 is an example of some screen definition settings related to input screens, Tab 704 is an example of screen definition settings related to confirmation screens, and Tab 705 is an example of screen definition settings related to selection screens. In the settings screen of Figure 7, the application software targeted for configuration displays a confirmation screen, "confirmation" (confirmation screen 1002 in Figure 10), which is a confirmation screen corresponding to Tab 704, after the user has registered on the input screen "inputForm" (input screen 1001 in Figure 10), to confirm whether the input items are correct. After that, it displays a selection screen, "PIC" (selection screen 1003 in Figure 10), which is a selection screen corresponding to Tab 705. Each input / output item (screen definition 402) in Figure 10 is set by the user (the developer, who is the user of the program development device 101) before the flowchart in Figure 5 is executed.

[0088] The detailed problems of this embodiment are described below.

[0089] For example, the application software defined in Figure 7 (as shown in Figure 10) is expected to transition sequentially from input screen 1001, which is configured in tab 703, to confirmation screen 1002, which is configured in tab 704, and then to selection screen 1003, which is configured in tab 705. By configuring routing for a single-page application, screen identification information (screen code) can be assigned to each screen, allowing direct transitions to the corresponding screen. For example, in the case of confirmation screen 1002, specifying the URI "localhost:8080 / _marketApp / #confirmation" will allow direct transitions to confirmation screen 1002 if routing is configured. However, since confirmation screen 1002 (i.e., the screen configured in tab 704) is a screen for confirming the values ​​entered in input screen 1001 (i.e., the screen configured in tab 703), directly entering the above URI is meaningless. In other words, it is necessary to create a single-page application that includes screens that should not be routed. The routing configuration technology for single-page applications is a technique for associating URIs in the same way as for regular multi-page applications, and it does not take into account the creation of screens that do not require routing configuration. Return to the explanation of Figure 7.

[0090] In Figure 7, the screen code input field 701 of the settings screen 700 displayed in tab 703 has "inputForm" entered in it. The value in screen code input field 701 corresponds to the tab name of tab 703, but tab 703 and screen code input field 701 do not have to be the same. If the tab name and screen code are different, they can be managed by linking the two with data or something similar. The value entered in screen code input field 701 (the value that becomes the string at the end of the URI of the screen to be configured) may be initially set to the tab name, and the initial value may be changed by the user entering a string.

[0091] Checkbox 702 is a checkbox (display item) that prompts the user to input whether to configure routing settings for the target screen (input screen 1001) in the settings screen open in Figure 7 (in this case, settings screen 700 displayed by specifying tab 703). In settings screen 700, the target screen (input screen) in tab 703 is a screen that can be directly accessed, so checkbox 702 is checked. In other words, checkbox 702 is a display item that accepts instructions on whether or not to assign identification information (URI) to the target screen that is displayed in the generated application software.

[0092] The settings screen 800 in Figure 8 is the settings screen that appears when tab 804 (the same as tab 704 in Figure 7) (the tab for selecting the "confirmation" screen) is selected, and it displays the input screen for the screen definition settings of the confirmation screen. The screen code input field 801 has the screen code name "confirmation" entered in it.

[0093] Checkbox 802 is a checkbox that prompts the user to input whether to configure routing settings for the screen targeted by the tab open in Figure 8 (in this case, 804). In the settings screen 800, the input confirmation screen for the settings target in tab 804 is a screen that we do not want the user to transition to directly, so checkbox 802 is unchecked. Return to the explanation of the flowchart in Figure 6.

[0094] The subsequent processing is performed using the screen definition information read in step S603 of Figure 6.

[0095] In step S604, the CPU 201 of the program development device 101 determines whether the screen code name (the code name entered in the screen code input fields 701 and 801) of the screen definition information read in step S603 is unique. If it is unique, the process proceeds to step S606; otherwise, it proceeds to step S605, where an error is detected and the application generation process is interrupted. This conditional branching ensures the uniqueness of the screen code name, and if routing is configured, it is possible to set a unique screen for each URI.

[0096] When the process transitions to step S606, the CPU 201 of the program development device 101 determines whether or not to perform routing settings (702 or 802) for the screen definition information read in step S603. If routing settings are to be performed (checkbox is ON), the process transitions to step S607; if routing settings are not to be performed (checkbox is OFF), the process transitions to step S608.

[0097] When the process transitions to step S607, the CPU 201 of the program development device 101 outputs the settings of the currently loaded screen definition as "history:true" to the routing configuration file. An example of the outputted routing configuration file is explained with reference to Figure 9.

[0098] Figure 9 shows an example of a routing configuration file according to an embodiment of the present invention.

[0099] Element 901 in Figure 9 represents the routing settings for the "inputForm" screen (input screen) configured in the settings screen 700 in Figure 7. Since checkbox 702 is ON (checked) in the settings screen 700, the screen UI (in the case of routing setting file 900, "inputForm," which is the target of settings in the settings screen 700) has its "history" parameter set to "true," and the routing settings are executed. In other words, the URI is given the identifier "inputForm" and the URI and UI screen are rendered.

[0100] On the other hand, when the process transitions to step S608, the CPU 201 of the program development device 101 outputs the currently loaded screen definition settings as "history:false" to the routing configuration file. An example of the outputted routing configuration file is explained with reference to Figure 9.

[0101] Element 902 in Figure 9 represents the routing settings for the "confirmation" screen (confirmation screen) configured in the settings screen 800 in Figure 8. Since checkbox 802 is OFF (not checked) in the settings screen 800, the screen UI (in the case of routing setting file 900, "confirmation," which is the target of settings screen 800) has the "history" parameter set to "false," and the routing settings are not executed. In other words, rendering of the URI and the UI screen is not performed. Return to the explanation of the flowchart in Figure 6. Refer to Figure 10 to explain the relationship between the URL and the rendering of the UI screen.

[0102] The input screen 1001 in Figure 10 is configured with routing settings enabled, as shown in checkbox 702 on the settings screen 700 (i.e., the "history" parameter is set to "true" as in 901). Therefore, the URI is displayed as "localhost:8080 / _marketApp / #inputForm" in the address bar 1004, and this URI allows direct navigation to the input screen 1001. It is also possible to bookmark the input screen 1001. Furthermore, it is possible to copy the URI output in the address bar and create a shortcut.

[0103] On the other hand, confirmation screen 1002 is configured so that routing settings are not executed, similar to checkbox 802 on settings screen 800 (i.e., the "history" parameter is "false" like in 902). Therefore, the URI is displayed as "localhost:8080 / _marketApp / # / " as shown in address bar 1005, and confirmation screen 1002 is not rendered as a URI. Even if you copy the string "localhost:8080 / _marketApp / # / " displayed in address bar 1005 and paste it into a blank address bar to perform a search, confirmation screen 1002 will not be displayed. In this case, either an error message will be displayed, or the top page of the generated simple application will be shown. In other words, the identification information for transitioning to confirmation screen 1002 is not output to the user of the generated application software (the user of client PC 104). Therefore, it is impossible to bookmark confirmation screen 1002. Furthermore, it is also impossible to create a shortcut to confirmation screen 1002.

[0104] As described above, this has the effect of easily configuring whether or not to render the URI and UI screen for each screen. In other words, for each of the multiple screens displayed by the generated application software, it is easy to configure whether or not to associate a URI (whether or not to output it to the user of the generated application software) with a simple operation of checking a checkbox.

[0105] In the next step, S609, the CPU 201 of the program development device 101 divides the process depending on whether there are other screens to render. If there are other screens, the process returns to step S603; if there are no other screens, the process shown in the flowchart in Figure 6 is terminated.

[0106] Through the above process, a mechanism can be provided to facilitate the development of single-page applications.

[0107] Specifically, in single-page applications, it is possible to easily create application software from a GUI that mixes pages with and without routing settings, which has the effect of allowing even non-highly skilled engineers to create single-page applications.

[0108] As described above, it goes without saying that the object of the present invention can also be achieved by supplying a recording medium containing a program that realizes the functions of the embodiments described above to a system or device, and by having the computer (or CPU or MPU) of that system or device read and execute the program stored on the recording medium.

[0109] In this case, the program read from the recording medium itself realizes the novel function of the present invention, and the recording medium on which that program is recorded constitutes the present invention.

[0110] For recording media used to supply programs, examples include flexible disks, hard disks, optical disks, magneto-optical disks, CD-ROMs, CD-Rs, DVD-ROMs, magnetic tapes, non-volatile memory cards, ROMs, EEPROMs, silicon disks, and the like.

[0111] Furthermore, it goes without saying that the functions of the aforementioned embodiments are realized not only by the computer executing the program it has read, but also by the operating system (OS) running on the computer performing some or all of the actual processing based on the instructions of that program, thereby realizing the functions of the aforementioned embodiments.

[0112] Furthermore, it goes without saying that this also includes cases where, after a program read from a recording medium is written to the memory of a function expansion board inserted into a computer or a function expansion unit connected to a computer, the CPU or other components of the function expansion board or function expansion unit perform some or all of the actual processing based on the instructions of the program code, and the functions of the aforementioned embodiments are realized through that processing.

[0113] Furthermore, the present invention may be applied to a system consisting of multiple devices or to a device consisting of a single device. It goes without saying that the present invention can also be applied when the results are achieved by supplying a program to a system or device. In this case, by reading a recording medium containing a program for achieving the present invention into the system or device, the system or device can enjoy the effects of the present invention.

[0114] The above program may consist of object code, program code executed by an interpreter, script data supplied to the OS (operating system), and the like.

[0115] Furthermore, by downloading and reading the program for achieving the present invention from a server, database, etc. on a network using a communication program, the system or device can enjoy the effects of the present invention. It should be noted that configurations combining the above-described embodiments and their variations are all included in the present invention. [Explanation of Symbols]

[0116] 101 Program Development Equipment 102 Program Development Server 103 Database Server 104 Client PCs 105 Execution Server 107 Network

Claims

1. A receiving means for receiving a setting as to whether or not to assign identification information for transitioning to an application screen to the application screen; a control unit that controls the generation of an application based on the setting received by the receiving unit, The control means generates an application capable of displaying a first screen that accepts a setting for allocating the identification information and a second screen that accepts a setting for not allocating the identification information. An information processing system comprising:

2. The control means generates an application that assigns the identification information to the first screen and does not assign the identification information to the second screen.

2. The information processing system according to claim 1,

3. The first screen can be transitioned to using the identification information, The second screen cannot be transitioned to using the identification information.

3. The information processing system according to claim 1 or 2,

4. The second screen is a screen displayed when a specific operation is accepted on the first screen or another second screen.

4. The information processing system according to claim 1, wherein:

5. The accepting means accepts whether or not to assign the identification information to the screen by switching whether or not the display mode is on or off.

5. The information processing system according to claim 1, wherein:

6. The application is a single-page application 6. The information processing system according to claim 1, wherein:

7. The accepting means inhibits the acceptance of the setting if the application is not a single-page application.

6. An information processing system according to claim 1, wherein:

8. The identification information of the first screen is a part of the URI of the first screen.

8. The information processing system according to claim 1, wherein:

9. Further comprising setting means for setting the identification information based on a value input by a user.

9. The information processing system according to claim 1, wherein:

10. The present invention further comprises a determination means for determining whether the identification information set by the setting means for each of a plurality of screens displayed by the application is unique with respect to the identification information of other screens, The control means controls to inhibit the allocation of the identification information to the screen when the identification information is determined by the determination means to be not unique, and / or controls to inhibit the generation of an application.

10. The information processing system according to claim 9,

11. the control means controls to generate an application based on screen definition information including input item definition information, output information definition information, and item layout definition information, each of which is information set by a user; The screen definition information is defined based on the settings accepted by the accepting means.

11. The information processing system according to claim 1,

12. A receiving step of receiving a setting as to whether or not to assign identification information for transitioning to a screen of an application to the screen; a control step of controlling to generate an application based on the setting received in the receiving step, The control step includes generating an application capable of displaying a first screen that accepts a setting for allocating the identification information and a second screen that accepts a setting for not allocating the identification information. A method for controlling an information processing system comprising the steps of:

13. A program for causing a computer to function as each of the means of the information processing system according to any one of claims 1 to 11.

14. 12. A computer-readable storage medium storing a program for causing a computer to function as each of the means of the information processing system according to any one of claims 1 to 11.

Images