JP4039842B2 - Screen transition method and screen transition program - Google Patents

Description

[0001]
[Technical field to which the invention belongs]
The present invention relates to a method and a program for controlling screen transition on a stateless protocol such as a web page.
[0002]
[Prior art]
In recent years, MVC (Model View Controller) architecture has become widespread in systems that dynamically display web pages. This is a method adopted as a standard in J2EE (Java (registered trademark) 2 Platform, Enterprise Edition), and aims to separate the screen interface and business processing. It is now possible to design a system using web pages.
[0003]
In the MVC architecture, the controller receives a request from a user and calls a model. The controller has knowledge of these in order to connect the view and the model. A model is synonymous with a command object and has a class name (class name) and a method (method name). The model performs business functions or defines behavior for data. The model is unaware of the controller and view. The view draws the screen based on information from the model.
[0004]
In the conventional MVC architecture, a method of controlling screen transitions using two parameters of a module name and a result is known. Here, the module name and the result screen are associated with each other, and a screen to be transitioned with execution of processing related to the module name is determined.
[0005]
For example, if product search, reference, registration, addition, and change functions are possible in ordering products, each of the module names of order search, order reference, order registration, order addition, and order change will succeed. In this case, a table in which information for specifying a screen to be transitioned in the case of failure and information for specifying a screen to be transitioned in the case of failure is used is associated.
[0006]
[Problems to be solved by the invention]
The conventional method has the following problems.
First, when a process related to a module is called from any screen, the screen is determined regardless of the calling screen. In order to avoid this, it is necessary to prepare module names that are remarkably finely divided or to finely divide the results. As a result, the types of values defined in the screen transition increase remarkably, and the definition itself becomes difficult.
[0007]
Dividing the module name or dividing the result value has the problem that it is practically equivalent to designating the transition destination screen.
Therefore, there has been a problem that the module must be divided or the module itself must be corrected in accordance with the change of screen transition or the addition of a new function.
[0008]
It is an object of the present invention to provide a screen transition technique that can control fine screen transitions with a simple structure and can also handle transition changes and screen additions without changing modules.
[0009]
[Means for Solving the Problems]
An object of the present invention is a method of transitioning a screen to be presented from one screen to another screen in response to a request, the screen being presented using a screen ID that uniquely identifies the screen Caused by the execution of the method of the command object, the information specifying the command object corresponding to the module executable on the screen, the information specifying the method called by the command object As a result of the processing, a step of providing a definition table defining at least one or more screen IDs to be transitioned, and a parameter indicating information specifying the command object and information specifying a method in relation to the certain screen are included. Accepting the request and referencing the definition table in response to accepting the request; The screen is associated with the specified screen ID and the step of specifying the screen ID to be transitioned according to the processing result together with the information specifying the command object and the information specifying the method, with the certain screen as the current screen ID. This is achieved by a screen transition method characterized by comprising a step of presenting a screen.
[0010]
According to the present invention, in the definition table, the screen ID to be transitioned is determined based on at least the current screen ID, the information specifying the command object, and the information specifying the method to be called. Therefore, the screen transition can be easily defined, and the information to be defined can be easily grasped.
In addition, by changing only the ID of the transition screen in the definition table or by changing the method to be called, it is possible to change or add a layout.
[0011]
In a preferred embodiment, the step of providing the definition table corresponds to each of the current screen IDs, at least a first screen ID indicating an image to be transitioned when the processing result is successful, and a process And defining a second screen ID indicating an image to be transitioned when the result is a failure. Of course, it is not limited to the binary value of success / failure, and it goes without saying that it can be applied to a unique screen transition and a screen transition that may branch into three or more.
[0012]
In another preferred embodiment, the step of providing the definition table includes a step of selectively setting information indicating an arbitrary command object as information for specifying the command object. This is a so-called wild card. That is, by preparing a wild card as information for specifying a command object in the definition table, for example, processing when a “return” button on a web page is turned on can be easily realized. In the conventional method, in order to realize this, it is necessary to prepare a module for realizing “return”. However, according to the above embodiment, it is not necessary to prepare a module.
[0013]
In still another preferred embodiment, the step of providing the definition table includes a step of selectively setting information indicating an arbitrary screen as information for specifying the current screen ID. In addition, the step of providing the definition table may include a step of selectively setting information indicating an arbitrary method as information for specifying the method. These correspond to the case where the current screen ID is a wild card and the method is a wild card, respectively.
[0014]
In a further preferred embodiment, the step of specifying the screen ID to be transitioned includes calling a method specified by information indicating the method of a class specified by information indicating a command object, A module related to a method includes a step of executing a predetermined process, and a handler that grasps the definition table based on a result of executing the process determines a screen ID to be transitioned.
[0015]
In a more preferred embodiment, the step of presenting the screen further comprises a step of dispatching to a page indicated by the screen ID according to the determined screen ID. More preferably, presenting the screen includes obtaining results from the associated module in response to the dispatch.
[0016]
Another object of the present invention is a program for operating a computer to transition a screen to be presented from one screen to another screen in response to a request, and a screen ID for uniquely identifying the screen. The current screen ID indicating the screen being presented, information identifying the command object corresponding to the module executable on the screen, information identifying the method called by the command object, and the command A step of providing a definition table defining at least one or more screen IDs to be transitioned as a result of the processing caused by the execution of the method of the object; and information and a method for specifying the command object in relation to the certain screen Receiving a request including a parameter indicating information to be identified; and the request In response to acceptance, referring to the definition table, the screen ID to be transitioned is specified according to the processing result together with the information specifying the command object and the information specifying the method with the certain screen as the current screen ID. The present invention is achieved by a computer-readable program that causes the computer to execute a step and a step of presenting a screen associated with the specified screen ID.
[0017]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. FIG. 1 is a block diagram showing an outline of a system according to an embodiment of the present invention. As shown in FIG. 1, in the present embodiment, client machines 14-1, 14-2,... And a server 16 are connected to the Internet 12. The server 16 can provide predetermined contents (for example, images) in response to various requests from the client machine 14.
Needless to say, the present invention is not limited to a form in which the client machine 14 can be connected to the server 16 via the Internet 12, and it goes without saying that the present invention can be applied to a machine connected via an arbitrary network such as a LAN or WAN.
[0018]
FIG. 2 is a block diagram showing the configuration of the server 16 according to the present embodiment. As shown in FIG. 2, the server 16 includes a first portion 20 corresponding to the controller, a second portion 22 corresponding to the model, and a third portion 24 corresponding to the view in the MVC model. is doing. The server 16 also has a model manager 26 that manages models.
[0019]
The first portion 20 includes a proxy servlet 30, a request processor 32, a command handler 34, a flow manager 36, and a command flow handler 40. The proxy servlet 30 receives a request (Http Request) transmitted to the server 16 by the user viewing the current page on the client machine 14 by operating the input device, and transmits the request to the request processor 32.
[0020]
The command handler 34 acquires parameters from the screen and calls an EJB (Enterprise Java Beans: registered trademark) object (command object). The command flow handler 40 reads a definition of screen transition described later, determines a screen ID, and sets a predetermined page (setPage).
The second portion 22 is composed of various commands EJB 42-1, 42-2,. In the present embodiment, an EJB is created for each business function. The EJB 42 selected and called by the command handler 34 accesses the database 44 and executes processing such as reading of a necessary object 46.
[0021]
The third portion 24 includes various JSPs (Java Server Pages: registered trademarks). For example, the third part 24 includes a final result page (Proxy.jsp) 48 given to the client machine and a page (Page.jsp) 50 constituting the page. Portlets (portlet.jsp) 52-1, 52-2,... Constituting Page.jsp are included. The page configuration according to the present embodiment will be described below.
[0022]
FIG. 3 is a diagram for explaining a so-called composite view. In the present embodiment, the screen 300 is divided into a plurality of components 301 to 303. Each part corresponds to JSP. For example, the header component 301 corresponds to a certain first JSP (header.jsp) 311, and the menu component 302 corresponds to a second JSP (menu.jsp) 312. The message component 303 corresponds to the third JSP (message.jsp) 313. By adopting the composite view, for example, when the screen transitions, it is possible to generate and give the same to the client machine such that the header component 301 and the menu component 302 are the same.
[0023]
FIG. 4 is a diagram showing a page configuration used in the present embodiment. As shown in FIG. 4, in this embodiment, a header screen component 411 and a footer image component 412 are arranged at the upper and lower portions of all images, respectively. 4A, an image (A01) 401 includes a header screen component 411, an order search condition screen component 413, and a footer screen component 412, while the other image (A02) 402 includes an order search condition. Instead of the screen component 413, an order list screen component 414 is included.
[0024]
FIG. 4B is a diagram showing the page configuration in more detail. As shown in FIG. 4B, Proxy.jsp (reference numeral 420) corresponding to the page is header.jsp (reference numeral 421) corresponding to the header screen part 411 and footer.jsp (reference numeral corresponding to the footer screen part 412). 422) and page.jsp (see reference numeral 430) that can vary depending on the image. Furthermore, page.jsp includes [portlet] .jsp (see reference numerals 433 and 434) which are various screen components.
[0025]
In the present embodiment, for example, the following are prepared as [portlet] .jsp.
ordersearch.jsp: Order search screen parts
orderlist.jsp: Order list screen parts
orderinput.jsp: Order input screen component
orderinfo.jsp: Order display screen parts
inventorysearch.jsp: Inventory search screen component
inventorylist.jsp: Inventory list screen component
Of course, the present invention is not limited to these, and it goes without saying that other screen components (for example, login screen components) are prepared.
[0026]
[Application Example 1]
In the present embodiment, IDs (screen IDs) are assigned to these screen components, and screen transitions as shown in FIG. 5 are defined. A table (definition table) 500 defining screen transitions is read by the EJB command flow handler 40. In the definition table 500, the screen ID (refer to reference numeral 501), command name (refer to reference numeral 502), method name (refer to reference numeral 503) of the currently displayed screen (used for display), and success The screen ID of the first result screen that transitions to (see reference numeral 504) and the screen ID of the second result screen that transitions in the case of failure (see reference numeral 505). This means that when the screen ID of the currently displayed screen is “X01 (login screen)”, the method name “login” is called based on the associated command name “login command”. ing. If the login is successful as a result of the user ID and password input by the user, the screen transitions to a screen with the screen ID “A01”. On the other hand, if the login fails, the screen ID is “X01”. "Is displayed on the screen.
[0027]
FIG. 6 is a diagram illustrating an example of transition between screens related to an order. In this example, a composite view is employed, and a header screen component 611 and a footer screen component 612 are commonly provided above and below each screen (for example, see reference numeral 601).
In this example, when the user tries to perform a search, the order search screen screen component 613 transits to the order list screen component 623 (see arrow 606). Transition to a screen component 633 (see arrow 607). In FIG. 6, transitions indicated by arrows 606 to 607 correspond to successful screen transitions defined in the columns 506 to 510 in FIG. 5, respectively.
[0028]
The screen transition process according to the definition shown in FIG. 5 will be described with reference to FIGS. FIG. 7 shows a case where, when the current screen ID = A01, the command name = order command, the method name = search is executed, and the screen transition is executed as a result of success (see reference numeral 506 in FIG. 5 and FIG. 5). FIG. 8 shows a case of failure.
7 and FIG. 8 and FIG. 13 and FIG. 14 to be described later, among the constituent elements shown in FIG. 2, for the sake of simplicity, the request processor 32 and the flow manager. 36 is omitted.
[0029]
In FIG. 7, when “Http Request” including parameters of command name = “order command” and method name = “search” is transmitted to the proxy servlet 30 (step 701), the EJB command handler 34 is called (step 702). ). The EJB command handler 34 calls the “find” method of the “OrderCommand” class in response to the command name = “order command” and the method name = “search” (step 703). As a result, the order command module 42-i searches for an object in the database 44. When a predetermined value or item can be found and the search is successful, the EJB command flow handler 704 is called (step 704).
[0030]
The EJB command flow handler 704 refers to the current screen ID, command name, method name, and search result (success) in the definition table (see FIG. 5) that has been read, and determines the screen ID = A02 to be transitioned to. . Thereby, the proxy servlet 30 dispatches to screen ID = A02 (step 705). The screen part “A02.jsp” includes the screen part “orderlist.jsp” (see arrow 706), and the screen part “orderlist.jsp” acquires the search result from the order command module 42-i. Thereby, a screen 602 (screen ID = A02) including the order list result component 623 can be acquired (see step 707).
[0031]
In FIG. 8, the processes related to steps 801 to 803 are the same as steps 701 to 703 in FIG. 7. When the order command module 42-i is called, a search is performed. In this case, a search result cannot be obtained because the search condition is invalid, that is, the search fails. In this case, the EJB command flow handler 40 called by the proxy servlet 30 (see step 804) reads the current screen ID, command name, method name, and search result (failure) in the definition table read (see FIG. 5). ) To determine the screen ID to be transitioned = A01. As a result, the screen 601 (screen ID = A01) including the order search condition screen component 613 is displayed again on the display device of the client machine.
Screen transitions described in the columns 507 to 510 (arrows 607 to 610 in FIG. 6) of the definition table 500 can be realized in the same manner.
[0032]
[Application Example 2]
Needless to say, this embodiment can also be used for other screen transitions, for example, screen transitions using composite views. FIG. 9 is a diagram illustrating an example of a definition table in another example (application example 2), and FIG. 10 is a diagram illustrating screen transition. This example is useful when the user wants to input while looking at a list of orders (order list screen parts) on each screen (see reference numerals 1011 and 1012 in FIG. 10).
[0033]
In application example 2, a screen with a different layout is constructed using the same command (order command) as application example 1 shown in FIGS. 5 and 6. That is, in the present embodiment, it is possible to construct another screen transition or screen layout by using the definition table, even though the same parts are used.
Transitions from the current screen to the result screen in the columns 901 to 907 in FIG. 9 correspond to the arrows 1001 to 1007 in FIG. 10, respectively.
[0034]
[Application Example 3]
If there is a need to input order data while looking at the inventory, a definition table as shown in FIG. 11 may be prepared. Here, command name = inventory command is added. FIG. 12 is a diagram for explaining screen transitions using the definition table. The transition from the current screen to the result screen in the columns 1101 to 1107 in FIG. 11 corresponds to the arrows 1201 to 1207 in FIG.
[0035]
As shown in FIG. 11 and FIG. 12, in the state where the screen with screen ID = C01 (order search screen) is displayed, parameters of command name = “order command” and method name = “add” are given, and the result Is successful, the screen can be changed to a screen (order change / addition screen) with screen ID = C03, which includes a stock search condition screen part, a stock list screen part, and an order input screen part. Further, in a state where the screen with screen ID = C02 is displayed, parameters of command name = “order command” and method name “reference” are given, and if the result is successful, the inventory search condition screen component, inventory list It is possible to transition to a screen (order confirmation screen) with screen ID = C04, which includes screen parts and order display screen parts.
[0036]
Regarding application example 3, an example of processing executed at the time of screen transition will be described in more detail with reference to FIGS. 13 and 14. FIG. 13 shows a case where screen transition is executed as a result of execution of command name = order command and method name = registration when screen ID = C03 (symbol 1105 and FIG. 11 in FIG. 11). 12 reference 1205).
[0037]
In FIG. 13, when “Http Request” including parameters of command name = “order command” and method name = “registration” is transmitted to the proxy servlet 30 (step 1301), the EJB command handler 34 is called (step 1302). ), The “reqist” method of the “OrderCommand” class is called (step 1303). Thereby, the order command module 42-p executes necessary registration processing (for example, data storage in the DB 44). If this is successful as a result of the registration process, the EJB command flow handler 40 is called (step 1304).
[0038]
The EJB command flow handler 40 refers to the current screen ID, command name, method name, and registration result (success) in the definition table (see FIG. 11) that has been read, and determines the screen ID = C04 to be transitioned to. Thereby, the proxy servlet 30 dispatches to image ID = C04 (step 1305).
[0039]
The screen part “C03.jsp” includes three screen parts “inventorysearch.jsp”, “inventorylist.jsp”, and “orderinfo.jsp”, and acquires information necessary for order input from the order command module 42-p. At the same time, an inventory list is acquired from the inventory command module 42-q. This includes inventory search condition screen parts (corresponding to “inventorysearch.jsp”), inventory list screen parts (corresponding to “inventorylist.jsp”), and order display screen parts (corresponding to “orderinfo.jsp”), An order confirmation screen (screen ID = C04) is displayed on the display device of the client machine (step 1306).
[0040]
Similarly, in FIG. 14, when the current screen ID = C03, command name = order command, method name = search is executed, and it is determined that the screen transition is executed as a result of the search (reference numeral in FIG. 11). 1106 and reference numeral 1206 in FIG. 12). In FIG. 14, when “Http Request” including parameters of command name = “stock command” and method name = “search” is transmitted to the proxy servlet 30 (step 1401), the EJB command handler 34 is called (step 1302). ), The “find” method of the “InventoryCommand” class is called (step 1403). Thereby, the inventory command module 42-q executes a necessary item search process. If this is successful as a result of the search processing, the EJB command flow handler 40 is called (step 1404).
[0041]
The EJB command flow handler 40 refers to the current screen ID, command name, method name, and search result (success) in the definition table (see FIG. 11) that has been read, and determines screen ID = C03 to be transitioned. Thereby, the proxy servlet 30 dispatches to image ID = C03 (step 1405).
[0042]
The screen part “C03.jsp” includes three screen parts “inventorysearch.jsp”, “inventorylist.jsp”, and “orderinput.jsp”, and acquires information necessary for order input from the order command module 42-p. At the same time, information indicating the search result is acquired from the inventory command module 42-q. As a result, an order change / addition screen consisting of an inventory search condition screen component, an inventory list screen component, and an order input screen component corresponding to each of the three screen components (“***. Jsp”) is displayed on the client machine display device. Is displayed.
[0043]
[Application Example 4]
Here, a description is added for an example using a wild card. In this example, a “return” button (return button) is arranged on any screen component of each screen, and the screen transition is defined when the user turns on (or clicks) the “return button”. FIG. 15 is a diagram illustrating a definition example of screen transition using a wild card. As shown in FIG. 15, for each current screen, regardless of the command name (indicated by an asterisk “*” in the figure), “Http Request” including a parameter of method name = return is When transmitted to the proxy servlet 30, processing in response thereto is executed.
[0044]
For example, if the current screen ID = A01 (see reference numeral 1501), the “return button” is specified for any command name, and if the processing result is successful, the screen ID = X02. Transition to a simple screen (see step 1601 in FIG. 16). As shown in FIG. 16, screen transitions (see arrows 1601 to 1604) that return to the original screen can be realized only by defining method name = return regardless of the command name. Note that columns 1501 to 1504 in FIG. 15 correspond to columns 1601 to 1604, respectively.
[0045]
As described above, according to the present embodiment, the screen ID to be transitioned is defined in association with the current screen ID, the module name, and the method name, respectively, for success and for failure. Therefore, a simple definition table can be used even for a multifunction module. For example, there are four types of functions, search, reference, registration, and change, for modules where the module name = order. If there are success / failures in each transition, it is necessary to define eight screen transitions. According to the present embodiment, a total of four screen transitions may be defined for each success / failure for each function.
[0046]
Also, there is no need to describe transition logic on the displayed screen. If the conventional method described above is taken, the result and the transition destination screen must be taken into consideration, which is substantially equivalent to describing the transition logic. On the other hand, according to the present embodiment, it is possible to implement by considering “what to do”, that is, “which method of the command is to be called”, for a button for screen transition.
[0047]
Furthermore, the layout can be freely defined without changing the command object. When the layout of the result screen is different, the result screen ID is different. In the conventional method, when the result screen ID (that is, the layout) that transitions from one module is increased, it is necessary to increase the number of results returned by the module. For this reason, in the conventional method, it was necessary to change the module body. On the other hand, according to the present invention, it is possible to cope with the problem simply by increasing the definition of the screen transition.
[0048]
For example, as shown in Application Example 1 and Application Example 2, the layout can be easily changed according to authority and role. As shown in Application Example 3, it is also possible to support a composite view having a plurality of functions.
As described above, according to the present embodiment, it is possible to realize various layouts by using the same command object and screen parts only by changing the definition table.
[0049]
The present invention is not limited to the above embodiments, and various modifications can be made within the scope of the invention described in the claims, and these are also included in the scope of the present invention. Needless to say.
For example, in the above-described embodiment, in response to “Http Request” which is a request from the client machine 14 connected to the Internet 12, the server 14 should execute the process and display it on the display device of the client machine 14. Although the screen is transitioned, the present invention is not limited to this. Screen presentation and transition between client machines / servers connected by another network, for example, WAN or LAN, screen presentation on a single computer and Needless to say, it can be applied to the transition.
[0050]
Further, in the application example 4 of the above-described embodiment, a screen transition related to a method of “return” of an arbitrary command name using a wild card (indicated by an asterisk “*” in FIG. 15) for the command name has been described. However, items that can use wildcards are not limited to command names, and wildcards may be used for current screen IDs and method names. For example, regarding application example 1 (see FIG. 5), if it is not necessary to consider another layout, all current screen IDs may be wild cards. It is also effective to use a current screen ID as a wild card when describing transition to the end screen when logging out.
[0051]
【The invention's effect】
According to the present invention, it is possible to control screen transitions with a simple structure and provide a screen transition method that can flexibly respond to screen transition changes and screen additions without changing modules (command objects). It becomes possible to do.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an outline of a system according to an embodiment of the present invention.
FIG. 2 is a block diagram showing a configuration of a server 16 according to the present embodiment.
FIG. 3 is a diagram illustrating a so-called composite view.
FIG. 4 is a diagram showing a page configuration used in the present embodiment.
FIG. 5 is a diagram showing an example of a definition table in the present embodiment.
FIG. 6 is a diagram showing screen transition using the definition table shown in FIG. 5;
FIG. 7 is a diagram illustrating a processing example in screen transition using the definition table according to the embodiment.
FIG. 8 is a diagram illustrating a processing example in screen transition using the definition table according to the embodiment.
FIG. 9 is a diagram showing another example of the definition table in the present embodiment.
10 is a diagram showing screen transition using the definition table shown in FIG. 9. FIG.
FIG. 11 is a diagram showing still another example of the definition table in the present embodiment.
FIG. 12 is a diagram showing screen transition using the definition table shown in FIG. 11;
FIG. 13 is a diagram illustrating a processing example in screen transition using the definition table according to the embodiment.
FIG. 14 is a diagram illustrating a processing example in screen transition using the definition table according to the embodiment;
FIG. 15 is a diagram showing still another example of the definition table in the present embodiment.
FIG. 16 is a diagram showing screen transition using the definition table shown in FIG. 9;
[Explanation of symbols]
14 Client machine
16 servers
30 Proxy servlet
32 Request processor
34 Command Handler
36 Flow Manager
40 Command flow handler

Claims (8)

In a screen including a plurality of screen parts, in response to a request, a method of transitioning a screen to be presented from a first screen to a second screen,
Using a screen ID that uniquely identifies the screen including the plurality of screen components, a current screen ID indicating the screen being presented, and information identifying a command object corresponding to a module executable on the screen; Providing a definition table that defines information for specifying a method called by the command object, and at least one screen ID to be transitioned;
Receiving a request including a parameter indicating information specifying the command object and information specifying a method in relation to any of the plurality of screen components of the first screen;
In response to accepting the request, the definition table should be referred to, the first screen should be the current screen ID, and information specifying the command object and information specifying the method should be transitioned according to the processing result. Identifying a screen ID;
Generating the second screen according to the identified screen ID and presenting the second screen, and
Providing the definition table comprises:
Setting information indicating an arbitrary command object as the information for specifying the command object,
The step of identifying the screen ID to be transitioned includes
In the definition information table, when the information specifying the command object related to the information specifying the current screen ID and the method is information indicating an arbitrary command object, how the information specifying the command object is determined. Regardless of this, the screen transition method includes a step of identifying a screen ID to be transitioned according to the current screen ID, information identifying the method, and the processing result . Providing the definition table comprises:
Corresponding to each of the current screen IDs, at least a first screen ID indicating an image to be transitioned when the processing result is successful, and an image to be transitioned when the processing result is unsuccessful. The screen transition method according to claim 1, further comprising a step of defining a second screen ID. Providing the definition table comprises:
Including setting information indicating an arbitrary screen as the information specifying the current screen ID,
The step of identifying the screen ID to be transitioned includes
In the definition information table, when the information specifying the current screen ID related to the information specifying the command object and the information specifying the method is information indicating an arbitrary screen, regardless of the current screen ID. 3. The screen transition method according to claim 1, further comprising a step of identifying a screen ID to be transitioned according to information identifying the command object, information identifying a method, and a processing result. . Providing the definition table comprises:
Setting information indicating an arbitrary method as the information for specifying the method,
The step of identifying the screen ID to be transitioned includes
In the definition information table, when the information specifying the method related to the information specifying the current screen ID and the command object is information indicating an arbitrary method, regardless of the information specifying the method, The screen transition according to any one of claims 1 to 3, further comprising a step of identifying a screen ID to be transitioned according to information identifying the command object, a current screen ID, and a processing result. Method. In a screen including a plurality of screen parts, in response to a request, a program for operating a computer to transition a screen to be presented from a first screen to a second screen,
Using a screen ID that uniquely identifies the screen including the plurality of screen components, a current screen ID indicating the screen being presented, and information identifying a command object corresponding to a module executable on the screen; Providing a definition table that defines at least one screen ID to be transitioned as a result of processing that is caused by the execution of the method of the command object, and information identifying a method called by the command object;
Receiving a request including a parameter indicating information specifying the command object and information specifying a method in relation to any of the plurality of screen components of the first screen;
In response to accepting the request, the definition table should be referred to, the first screen should be the current screen ID, and information specifying the command object and information specifying the method should be transitioned according to the processing result. Identifying a screen ID;
Generating the second screen according to the specified screen ID and presenting the second screen, causing the computer to execute the step,
In the step of providing the definition table,
As the information for specifying the command object, causing the computer to execute a step of setting information indicating an arbitrary command object,
In the step of identifying the screen ID to be transitioned,
In the definition information table, when the information specifying the command object related to the information specifying the current screen ID and the method is information indicating an arbitrary command object, the information specifying the command object is not related. First, a computer-readable program that causes the computer to execute a step of specifying a screen ID to be transitioned according to a current screen ID, information for specifying a method, and a processing result. In the step of providing the definition table,
Corresponding to each of the current screen IDs, at least a first screen ID indicating an image to be transitioned when the processing result is successful, and an image to be transitioned when the processing result is unsuccessful. 6. The program according to claim 5, wherein the computer is caused to execute a step of defining a second screen ID. In the step of providing the definition table,
As the information for specifying the current screen ID, the step of setting information indicating an arbitrary screen is executed by the computer,
In the step of identifying the screen ID to be transitioned,
In the definition information table, when the information specifying the current screen ID related to the information specifying the command object and the information specifying the method is information indicating an arbitrary screen, regardless of the current screen ID. 7. The computer according to claim 5, further comprising: causing the computer to execute a step of specifying a screen ID to be transitioned according to information specifying the command object, information specifying a method, and a processing result. The listed program. In the step of providing the definition table,
As the information for specifying the method, causing the computer to execute a step of setting information indicating an arbitrary method,
In the step of identifying the screen ID to be transitioned,
In the definition information table, when the information specifying the method related to the information specifying the current screen ID and the command object is information indicating an arbitrary method, regardless of the information specifying the method, 8. The computer according to claim 5, further comprising: a step of specifying a screen ID to be transitioned according to information specifying the command object, a current screen ID, and a processing result. The program described in.

Images