JP2014059699A - Demo application generation system and demo application generation program - Google Patents

Abstract

A demo application generation system for easily generating a demo application operable in a stand-alone environment for a Web application is provided.
When a Web application program generates and outputs a screen to a client terminal 200, HTML data 102 is acquired from an output buffer, and a URL expression or path included in the HTML data 102 is specified on the client terminal 200. Are converted into first local paths based on the directory of the client, and the path of the location of the HTML data 102 is converted into a second local path, and the second local path on the client terminal 200 is converted from the HTML data 102 to the second local path. The HTML file is output, and each file including the resource 104 referred to by the HTML data 102 is output or copied to the corresponding first local path on the client terminal 200.
[Selection] Figure 1

Description

  The present invention relates to a Web application program development technique, and more particularly to a technique that is effective when applied to a demo application generation system and a demo application generation program that generate a demo application that operates in a stand-alone environment.

  A system or service based on a Web application program is mainly executed when a user accesses an application program operating on a Web server using a Web browser operating on a client terminal. A user interface is provided to the user via a Web browser.

  By simply reproducing this user interface (screen contents, screen transitions, etc.), the functions, operations, screen layout, processing procedures, etc. of the system and services can be communicated to other customers and system users. In some cases, a demonstration application program, prototype, or the like (which may be collectively referred to as “demo application” hereinafter) for explaining or confirming contents may be required. In order to operate a service or a function by a Web application, a configuration in which a Web server and a client terminal are originally connected via a network is necessary, but such a configuration cannot be prepared for executing a demonstration. There are also many.

  On the other hand, for example, by introducing a Web server program to a demonstration client terminal and operating the Web server function locally, the demonstration environment is realized as a configuration in which the Web application is executed in a stand-alone environment of only the client terminal. There is a case. However, such a configuration increases the burden on the client terminal. On the other hand, it is also common to create an application that can operate in a stand-alone environment with only a client terminal, and use it for a demonstration or as a prototype. For example, it is possible to directly develop an application program that can be deployed as an original Web application program on a client terminal (see, for example, Non-Patent Document 1).

  In addition to the original Web application program, a demo application that can operate by directly accessing a local file in a stand-alone environment without using HTTP (HyperText Transfer Protocol) may be created based on the original Web application. Done.

  For example, first, a Web server is accessed via a Web browser of a client terminal, an original Web application program is once operated, and a screen is displayed on the Web browser. At this time, the source code of HTML (HyperText Markup Language) is displayed by the function of the Web browser, and the path referring to the file or resource on the Web server is displayed in the folder corresponding to the local environment of the client terminal. After converting the path to refer to the directory, it is stored locally as an HTML file. Also, for the resources to be referred to, the paths are converted in the same manner as described above as necessary.

  Further, these resource files are acquired from the Web server and stored in a predetermined local path of the client terminal. A demo application that operates in a stand-alone environment of the client terminal by performing the procedure of allocating the HTML file and necessary resources on the client terminal side on each screen of the necessary screen transition in the Web application in such a procedure. It is possible to create.

Microsoft, “.NET Framework 4 File System Website Project”, Internet <URL: http://msdn.microsoft.com/en-us/library/e5x4xz73>

  For example, for a web application that has already been developed, using the method described above, the path, etc., of the HTML source code output for each screen transition screen is converted and the files and resources are stored locally. Thus, it is possible to create a demo application that operates in a stand-alone environment in a Web browser such as a client terminal. However, the above-described method involves a lot of manual processes and procedures for creation, and is highly likely to cause leakage in conversion of paths and the like.

  Therefore, an object of the present invention is to provide a demo application generation system and a demo application generation program that easily generate a demo application operable in a stand-alone environment for a Web application in an operable state. The above and other objects and novel features of the present invention will be apparent from the description of this specification and the accompanying drawings.

  Of the inventions disclosed in this application, the outline of typical ones will be briefly described as follows.

  A demo application generation system according to a representative embodiment of the present invention calls a corresponding business logic in response to a request from a client terminal, and displays a processing result by the business logic in response to the client terminal. A demo application generation system that operates a Web application program that provides a service to the client terminal and generates a demo application that can reproduce the predetermined screen transition of the Web application program independently on the client terminal. However, it has the following characteristics.

  That is, when the Web application program generates and outputs a screen that responds to the client terminal, the demo application generation system acquires the HTML data from an output buffer that holds the generated HTML data of the screen. The URL expression or path included in the HTML data is converted into a first local path based on a predetermined directory on the client terminal, and the path of the location of the HTML data is converted to the predetermined path. Convert to a second local path relative to the directory.

  Further, as the demonstration application, an HTML file composed of the HTML data is output to a location indicated by the second local path on the client terminal, and the client includes a resource including a resource referred to by the HTML data. It is characterized in that it is output or copied to the location indicated by the corresponding first local path on the terminal.

  The present invention can also be applied to a program that causes a computer to operate as a demo application generation system as described above.

  Among the inventions disclosed in the present application, effects obtained by typical ones will be briefly described as follows.

  That is, according to the exemplary embodiment of the present invention, it is possible to easily generate a demo application that can operate in a stand-alone environment for a Web application that is in an operable state.

It is the figure which showed the outline | summary about the structural example of the demo application production | generation system which is one embodiment of this invention. It is the figure which showed the outline | summary about the example of the process at the time of displaying the input / output item of the column corresponding by the parts object in one embodiment of this invention on a screen. It is the flowchart which showed the outline | summary about the example of the flow of a process which produces | generates local data from HTML data in one embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted.

<Overview>
The demo application generation system according to an embodiment of the present invention is, for example, a screen transition of a so-called CRUD (Create, Read, Update, Delete) type Web application program that operates on a Web server and accesses a business database. This is a Web server system that can easily generate a demo application that can be reproduced independently in a stand-alone environment such as a Web browser of a client terminal.

  In the present embodiment, for example, in a CRUD type Web application program, input / output items on the screen (for example, input items for specifying the contents of search conditions for acquiring data from a business database and contents of search results are displayed. Instead of directly using a standard control object (hereinafter simply referred to as “control”) to display the content related to the output item to be displayed), the display name and control as described later are used. It is assumed that a part object in which data of setting contents, control processing, and explanatory text are integrated is used.

  This part object can specify what kind of control to display on the screen (for example, text control only, (text control and) input field, (text control and) drop-down list, etc.) as a parameter. Is possible. Control attribute values (for example, text content displayed in text controls, input field length, etc.), control information (for example, how to check validity of input data, etc.) It is also implemented to display and control controls according to specified content.

  In other words, the part object is displayed by combining an input / output control that handles input / output item data such as an input field, drop-down list, and text, and a label control that is a text control that displays the name of the input / output item. In this configuration, the output pattern of these controls can be specified.

  At this time, the attribute value such as the width of the control can be adjusted in a consistent manner for the label control and the input / output control at a time, so the attribute value etc. There is no need for a complicated process of designating, and the appearance of the displayed control can be adjusted. For this adjustment, for example, the display width of the label control and the input / output control is prevented so that the label control is not line-breaked at an unintended location or is not line-breaked at the intended location. For example, to adjust the unity.

  In the present embodiment, it is assumed that the source code is created so that the Web application program displays the contents relating to each input / output item on the screen using the part object. That is, the control is indirectly displayed using the part object (the HTML data or the script that displays the target control when the part object is executed on the Web server system is dynamically generated). Information relating to the mapping between each column of the database to be accessed and input / output items on the screen includes identification information (for example, column name) of each column of the database and identification information (for example, HTML of the corresponding part object). It is stored on the source code as mapping information with (ID attribute value).

  Furthermore, in this embodiment, as will be described later, the text displayed on the label control in each part object, the attribute value of the input / output control and the information related to the control processing, etc. are directly directly on the source code. Instead of specifying, it is configured to be stored as dictionary data associated with identification information such as part object ID or corresponding database column name. This makes it possible to dynamically change the display method of the screen and the appearance and attributes of the controls displayed on the screen by the part object without changing the source code once generated.

  In addition, by implementing the functions that part objects have in common, such as access to the above dictionary data, in the inheritance source class, during development, each part object is created by inheriting the class, A developer can develop a Web application program without implementing the function of a part object each time.

  Here, the demo application generation system according to the present embodiment is configured such that when the user actually operates the web application program to change the screen, the web server program generates and outputs each screen by the web server program. Based on the HTML data of the screen stored in the output buffer, local data obtained by converting the path and the like so that the client terminal can operate locally is automatically generated. This local data is transmitted and stored together with necessary resources to a predetermined folder or directory (having the same hierarchical structure as that on the Web server) of the client terminal.

  By such a method, a demo application that operates independently on the client terminal and that corresponds to the screen transition of the executed Web application can be automatically generated. In addition, as described above, the generation of the demo application by such a method has been conventionally performed manually by the user manually for each screen. On the other hand, in the present embodiment, such a demo application generation process can be automatically performed, and the load on the user can be greatly reduced.

  In this embodiment, the Web application program is developed using the above part object. However, in this embodiment, as described above, the Web application program is based on the HTML data of the screen accumulated in the output buffer. As long as it is possible to implement a process for acquiring HTML data from the output buffer in order to generate a demo application, it is not limited to those using the above part object, and any Web application program is also targeted. can do.

<System configuration>
FIG. 1 is a diagram showing an outline of a configuration example of a demo application generation system according to an embodiment of the present invention. The demo application generation system 100 includes, for example, computer devices such as server devices and virtual servers in a cloud computing environment. In addition to middleware such as an OS, a DBMS (DataBase Management System), and a Web server program (not shown), the user This is a Web server system having various components such as a request processing unit 110, a dictionary processing unit 120, a business logic 130, and a response processing unit 140, which are implemented by a created source code 101 or a software program such as a library or an object called from the source code 101 .

  In addition, the demo application generation system 100 responds to a request from a program such as a web browser (not shown) on the client terminal 200 connected via the network 300 such as the Internet to the business database (DB) 131 by the business logic 130. The service is provided by accessing and processing, and outputting the HTML data 102 to the client terminal 200 and responding.

  The request processing unit 110 has a function of receiving a request from the client terminal 200 and calling a content (business logic 130) based on the corresponding source code 101, an ID conversion unit 111 implemented by a software program, and an input Each unit includes a check unit 112 and the like. The ID conversion unit 111 uses the mapping information held in the source code 101 to identify the identification information (ID) of the part object 103 described in the source code 101 corresponding to the input item on the screen included in the request message. And a function of converting into column identification information (column name or the like) of the business DB 131 corresponding to the input / output item.

  This mapping information holds the correspondence between the identification information (for example, HTML ID attribute value) of the part object 103 displayed on the screen and the identification information (column name, etc.) of each column of the business DB 131 to be accessed. . Thereby, as will be described later, each part object 103 arranged on the screen in the source code 101 first acquires a column name corresponding to its own ID by the ID conversion unit 111, and then uses the column name as a key. Subsequent processing such as access to the business DB 131 and acquisition of dictionary data from the dictionary table 121 described later can be performed.

  Therefore, on the HTML data 102 that responds to the client terminal 200, it is not necessary to directly specify the column name of the corresponding business DB 131 as information such as a key in each part object 103 (control displayed by), and the ID of its own ID Therefore, it is possible to conceal the actual column name from the HTML data 102 to enhance security. Instead of performing such conversion, the column name of the business DB 131 corresponding to each part object 103 on the HTML data 102 may be directly specified as information such as a key.

  The input check unit 112 has a function of performing a general validity check on the content of the data of the input item specified via the part object 103 on the screen included in the request message. Possible types of validity checks include, for example, the number of characters and character type (numbers, alphabets, kana, full-width, etc.), restrictions on usable characters, format checks such as date and time, and various code values.

  The content of the validity check can vary depending on the language environment of the system (particularly the client terminal 200), for example. Therefore, in the present embodiment, the input check unit 112 implements a plurality of patterns of validity checking types that take into account variations for each language, and determines which type to use for the target input item in the language environment. It shall be selected and determined accordingly. Here, the dictionary table 121 of the target language is accessed via the dictionary processing unit 120 to be described later, and the validity check type information is acquired and determined from the contents of the dictionary data corresponding to the target input item. And

  The dictionary processing unit 120 includes a dictionary table 121 implemented by a database, a file table, or the like. For example, a specified key (in this embodiment, for example, a target input / output item (part object) 103) and obtains and outputs dictionary data for the column name of the business DB 131 corresponding to (103). For example, a plurality of dictionary tables 121 may be prepared for each category such as a target language environment or a business type of a Web application program, and may be selected and used.

  The contents and format of the dictionary data in the dictionary table 121 are not particularly limited. In the present embodiment, as a simple method, for example, as will be described later, various data necessary for performing input / output processing of data to a target column of the business DB 131 via a screen (for input / output) It is assumed that the attribute value of the part object 103, parameters necessary for control, etc.) are specified in a predetermined order by comma separation or the like.

  Specifically, for example, the display name that is the content when displaying the label control in the corresponding part object 103, the length (number of characters) when the input field is displayed as the input / output control, the type of validity check, Designation related to the contents of control processing such as IME mode, abbreviated display name and display width which are shortened texts when displaying output data in a table, a value list when displaying with a drop-down list, etc. It is done.

  In the example of FIG. 1, the dictionary processing unit 120 is configured to be mounted on the demo application generation system 100. However, the configuration is not limited to this, and the dictionary processing unit 120 is configured independently on a server device different from the demo application generation system 100. May be.

  The business logic 130 has a function of performing processing as a business application using the business DB 131. In the present embodiment, as described above, the CRUD type application for the business DB 131 is targeted, but the present invention is not particularly limited to this.

  The response processing unit 140 has a function of generating HTML data 102 based on the processing result of the business logic 130 based on the contents of the source code 101 and responding to the client terminal 200, and is a display implemented by a software program Each unit includes an adjustment unit 141, a display unit 142, a local data generation unit 143, and the like.

  The display adjustment unit 141 acquires, for each output item included in the response, parameter values such as label control text, input / output control attribute values, and control information for displaying the corresponding part object 103. Here, the dictionary table 121 such as the corresponding language environment is accessed via the dictionary processing unit 120, and various parameter values such as display names and attribute values are obtained from the dictionary data corresponding to the target output item (part object 103). get.

  The display unit 142 arranges controls displayed by each part object based on parameter values such as label control text, input / output control attribute values, and control information obtained by the display adjustment unit 141. A function to generate HTML data 102 of the response screen.

  The local data generation unit 143 generates local data 105 based on the HTML data 102 generated by the display unit 142, and transmits the local data 105 together with the necessary resources 104 to a predetermined folder or directory of the client terminal 200 for storage. Thus, the client terminal 200 has a function of generating a demo application.

  Specifically, for example, when the HTML data 102 stored in the output buffer of a Web server program (not shown) is output to the client terminal 200, it is acquired. Specifically, this timing is, for example, “immediately before” to output, and in the present embodiment, since each control displayed on the screen is displayed using the part object 103, for example, the part object 103 is displayed ( In a common class or the like for generating a screen by generating HTML, a predetermined method or the like may be called when writing the last HTML tag ("</ html>").

  Unlike the present embodiment, even when the part object 103 is not used for screen display, for example, by adding one line of code that calls a predetermined method at the end in common with each screen, for example. Similar processing may be performed. In addition, any means that can catch an event when screen generation is completed, such as execution when a debug code such as a trace point or log output at the end is called, can be used as appropriate.

  For the HTML data 102 acquired from the output buffer when the screen generation is completed, the local data generation unit 143 further performs path conversion as described later so that the HTML data 102 can be operated in the stand-alone environment of the client terminal 200. Etc. to generate local data 105. Similarly, path conversion or the like is performed for the necessary resources 104 such as image data and other script files referred to by the HTML data 102. The generated local data 105 and necessary resources 104 are transmitted to a predetermined folder or directory of the client terminal 200 and stored.

  The client terminal 200 uses a Web browser or the like to access a demo application including the local data 105 stored in a predetermined local folder or directory and the necessary resources 104, so that a stand-alone environment is not required. Thus, it is possible to reproduce the screen contents and screen transition of the Web application.

<Web application screen display processing>
FIG. 2 is a diagram showing an outline of an example of processing when the input / output items of the corresponding column are displayed on the screen by the part object 103 in the CRUD type application. In the example of FIG. 2, an example in which an input field for specifying “customer name” is displayed on a screen for inputting a search condition when reading data from the business DB 131 is shown.

  In the source code 101 of the Web application program shown in the upper part of the figure, the part object 103 is called to display an input field for designating “customer name”. Specifically, first, the column name corresponding to the ID (“A01”) from the mapping information held in the source code 101 (in the example of FIG. 2, the correspondence is held by array ()). Get "customer_name") information.

  Thereafter, for example, a subclass inherited from a class that implements the function of the part object 103 is called in the form of creating an instance (“CF_itemDic ();”). In the example of FIG. 2, as part of the parameters, the type of dictionary table 121 to be called (“common dictionary”), the type of input / output control to be displayed (“input field”), the ID attribute value of HTML (“A01”), etc. The state called by specifying is simplified. The HTML ID attribute value (“A01”) is dynamically converted into a column name (“customer_name”) by mapping information.

  The part object 103 called by such a code holds, as data, at least information on the logical element of the label (text of the label control) as the display name and the logical element related to the contents of the input / output control to be displayed. . Further, as shown in FIG. 2, information may be held for a logical element of a comment made up of text or the like that describes the contents. In the example of FIG. 2, among the above three logical elements of the part object 103, since “input field” is specified as a parameter in the source code 101 for the control, this is set.

  The called part object 103 further accesses the target dictionary table 121 (“common dictionary”) via the dictionary processing unit 120 by a predetermined function or method, and corresponds to the column name (“customer_name”). Dictionary data (a set of a plurality of values such as “customer name”, 40 characters, 20 characters,... In this embodiment) is acquired.

  In the example of FIG. 2, as dictionary data in the dictionary table 121, in order from the top, the name (text to be displayed on the label control), the length in the case of the input field (number of characters in half-width), and the maximum length in the case of the input field (Number of characters), validation type of input data, initial mode of IME, explanatory comment, text (display name) for list display in table, display width (pixel value) for list display in table, etc. Information shall be retained. As an output format when acquiring these dictionary data, for example, a series of character strings in which these values are separated by a comma or the like may be used, or easily accessible data such as an associative array may be used.

  For the dictionary table 121, considering the processing efficiency, it is desirable to expand the contents of the dictionary data in the memory at the time of initial processing or first access. In this case, if all the dictionary data is expanded, the processing efficiency may be reduced due to the pressure on the memory usage or the time required for the expansion processing. Therefore, in terms of implementation, it is desirable that dictionary data in a necessary range can be expanded on a memory when necessary.

  Therefore, in this embodiment, there is a hierarchical structure including a plurality of dictionary tables 121 having different application ranges, and these are appropriately selected and used. For example, a common dictionary (“common dictionary”) for a system operating on the demo application generation system 100 or the entire application (“common dictionary”), a common dictionary only in a designated website (“site dictionary”), and only in a subsystem Assume that a plurality of types of dictionary tables 121 having different application ranges, such as a common dictionary (“library dictionary”) and a dictionary in units of screens (“controller dictionary”), are used.

  In this case, for example, when the corresponding dictionary data is not obtained by referring to a dictionary having a narrow application range such as the “controller dictionary”, the upper order is “library dictionary” → “site dictionary” → “common dictionary”. Reference may be made retrospectively to the dictionary table 121 (which has a wide application range). Further, a default value may be used or an error may be assumed if dictionary data is not obtained.

  The part object 103 extracts necessary data from the acquired dictionary data, and sets it as a parameter when displaying or controlling the control. For example, the length of the field acquired from the dictionary data is set as an attribute value when an input field is displayed as an input / output control, the value of the validity check, the initial mode of IME, the contents of the explanation comment, etc. Set. The processing related to input / output control such as validity checking of input data and IME mode setting is a function of the input check unit 112 and the display unit 142. Specific implementation includes, for example, parts It is assumed that the part object 103 is implemented as a function that the part object 103 has or can be called by, for example, defining it as a method in the inheritance source class of the object 103.

  As a result, as shown in the example of the lower screen 201 in FIG. 2, the part object 103 can generate the HTML data 102 so as to display the control of the input field for designating the “customer name” at the time of execution. . At this time, for example, information on an explanatory comment of the part object 103 can be used as help information for the input / output item.

  When displaying the input field, since only the input field control is displayed, it is unclear what should be input. Therefore, in this embodiment, as shown in FIG. A text control that displays the input / output item display name (“customer name”) is displayed adjacent to the input field as a label (label control). The text sets the label information in the data held by the part object 103, that is, the name value (“customer name”) of the dictionary data acquired by the part object 103 from the dictionary table 121.

  Such processing related to the generation of the HTML data 102 is a function of the display unit 142 or the like. As a specific implementation, for example, a part is defined as a method in a class inherited from the part object 103. It is assumed that the object 103 is implemented as a function that the part object 103 has or can be called. Note that here, as described above, the layout and appearance of the label control and input / output control to be displayed, and the comment control to display the explanatory comment as one unit, the layout and appearance in a consistent manner. The attribute value etc. related to

  The HTML data 102 generated by the display unit 142, the display adjustment unit 141, and the like of the response processing unit 140 and stored in the output buffer of the Web server program (not shown) is output to the client terminal 200 by the above processing. Immediately before, the local data generation unit 143 acquires this and generates the local data 105. In the present embodiment, as described above, for example, the last HTML tag (“</ html>”) is displayed in a common class or the like for displaying the part object 103 (generating HTML) and generating a screen. This is executed by calling a predetermined method or the like when writing.

<Local data generation processing>
FIG. 3 is a flowchart showing an outline of an example of a flow of processing for generating the local data 105 from the HTML data 102. As described above, the local data generation unit 143 generates the timing immediately before the HTML data 102 of each screen in the screen transition is generated and output to the client terminal 200 (when the screen generation including the HTML data 102 is completed). Called. When called, first, the HTML data 102 stored in the output buffer of the Web server program (not shown) is extracted, and for each HTML tag described therein, tabs and indents are provided for each hierarchy so that they can be easily seen as necessary. Set and edit to make a staircase (S01).

  Next, the path of the file or resource 104 described in the HTML data 102 is converted (S02). Specifically, for example, "href =" / "or" href = '/ "," src = "/" or "src =' /", "url ('/", "url (" / ", etc. Is converted into a local path following “file: ///”.

  Here, the local path conversion means that when the path expression is an absolute path starting with “/”, a predetermined directory or folder (for example, “c: \ design” or the like serving as a storage destination reference on the client terminal 200). (Hereinafter referred to as “Output directory”) is added to the beginning to obtain the local path. On the other hand, in the case of a relative bus whose path expression starts with “../”, the absolute path of the location traced back in the route direction on the demo application generation system 100 by the number of “../”. After acquisition, the local path is obtained by prefixing the character string of the output destination directory. The format of the character string of the local path is appropriately converted according to the platform of the client terminal 200. At this time, if the URL ends with “/”, “index.html” is used as the file name, and the file name of the parameter portion is also synchronized with the file name when it is copied to the client terminal 200 in the processing described later. , Convert to a file name appropriate for the platform. Note that the value of the output destination directory can be set and registered as dictionary data in the dictionary table 121, for example.

  Thereafter, local path conversion is also performed on the arrangement location of the HTML data 102 itself to obtain the arrangement location path, and the converted HTML data 102 is output to the arrangement location on the client terminal 200 as a file (S03). If a folder or directory does not exist at the location, it is created and output.

  Further, a file corresponding to the path converted to “file: ///...” In the HTML data 102 in step S 02 is extracted from the resource 104 (S 04), and the URL expression described inside each extracted file. Is converted into a local path (S05), and the converted file, resource 104, and the like are output or copied to a predetermined location on the client terminal 200 (S06).

  For example, when the extracted file is a CSS (Cascading Style Sheets) file, the above-mentioned local path conversion is performed on the image file in “url (...)” And the location of the path on the client terminal 200. The image file is copied from the resource 104. In addition, local path conversion is performed for the location of the CSS file itself to obtain the location location path, and the converted CSS file is output to the location on the client terminal 200.

  If a compressed file is used in the CSS file, the file before compression is specified on the server in advance after the file can be specified by a naming rule or the like. Process. Similarly, an external file is also preliminarily arranged on the server after a conversion rule with an arrangement location on the server is determined so that the external file can be specified.

  If the extracted file is a JS file (JavaScript (registered trademark) external file), the image file in the JS file is extracted to perform local path conversion, and a resource is placed at the location of the path on the client terminal 200. The image file is copied from 104. Also, the internal path consisting of each URL expression in the JS file is converted to a local path. Furthermore, local path conversion is also performed for the location of the JS file itself to obtain the location location path, and the converted JS file is output to the location on the client terminal 200.

  If the extracted file is an image file, the image file is copied from the resource 104 to the corresponding location on the client terminal 200 with respect to the path of the image file that has already undergone local path conversion in the converted HTML data 102. .

  Through a series of processes as described above, when a user executes a web application to change the screen, a demo application that can display each screen independently on the client terminal 200 is automatically generated and the client It is possible to output on the terminal 200.

  Note that, for example, setting information indicating whether or not to enable a function for generating a demo application is held in the demo application generation system 100, and if the function is disabled, the Web application is executed and screen transition is performed. You can prevent the demo application from being generated. Further, the demo application generation system 100 may be constructed by being combined with a development environment of a Web application program, and the demo application may be generated in accordance with an operation such as confirmation of a developed screen or simulation.

  As described above, according to the demo application generation system 100 according to an embodiment of the present invention, once a user causes a Web application to be executed once via the client terminal 200 and the screen is changed, the screen transition is performed. For each of the screens included, the necessary HTML files and resource files with the same URL structure as the demo application generation system 100 (Web server) can be automatically placed under a predetermined output destination directory on the client terminal 200. It is possible to automatically generate a demo application that operates independently on the client terminal 200. As a result, it is possible to significantly reduce the load of creating the demo application.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

  For example, in addition to the generation of the demo application as described above, for example, the system according to the present embodiment is applied to a system that compresses and distributes a local file composed of an HTML file, a JS file, and a CSS file in the ZIP format or the like. It is also possible to apply the data generated in.

  The present invention is applicable to a demo application generation system and a demo application generation program that generate a demo application that operates in a stand-alone environment.

DESCRIPTION OF SYMBOLS 100 ... Demo application production system 101 ... Source code 102 ... HTML data 103 ... Parts object 104 ... Resource 105 ... Local data 110 ... Request processing part 111 ... ID conversion part 112 ... Input check part 120 ... dictionary processing unit, 121 ... dictionary table, 130 ... business logic, 131 ... business database (DB), 140 ... response processing unit, 141 ... display adjustment unit, 142 ... display unit, 143 ... local data generation unit,
200 ... Client terminal, 201 ... Screen,
300: Network.

Claims (4)

Web application program that provides a service to the client terminal by calling a corresponding business logic in response to a request from the client terminal and displaying the processing result of the business logic in response to the client terminal A demo application generation system for generating a demo application that can be reproduced by the client terminal alone with respect to a predetermined screen transition of the Web application program,
When the Web application program generates and outputs a screen that responds to the client terminal, the HTML data is acquired from an output buffer that holds the generated HTML data of the screen, and is included in the HTML data A URL expression or path is converted into a first local path based on a predetermined directory on the client terminal, and a path of the location of the HTML data is converted to a second path based on the predetermined directory. Convert to local path,
As the demo application, an HTML file composed of the HTML data is output to a location indicated by the second local path on the client terminal, and each file including a resource referred to by the HTML data is output on the client terminal. A demo application generation system, characterized in that each is output or copied to a location indicated by the corresponding first local path. The demo application generation system according to claim 1,
A demo application generation system that converts, for each file including the resource referred to by the HTML data, a URL expression or path included in the file into a third local path based on the predetermined directory. . In the demo application generation system according to claim 1 or 2,
Demonstration characterized in that a hierarchical structure below the predetermined directory composed of the first and second local paths corresponds to a hierarchical structure of a directory in which files and resources related to the Web application program are arranged. Application generation system. Web application program that provides a service to the client terminal by calling a corresponding business logic in response to a request from the client terminal and displaying the processing result of the business logic in response to the client terminal A demo application generating program that causes a computer to operate as a Web server system that generates a demo application that can be reproduced independently by the client terminal with respect to a predetermined screen transition of the Web application program,
When the Web application program generates and outputs a screen that responds to the client terminal, the HTML data is acquired from an output buffer that holds the generated HTML data of the screen, and is included in the HTML data A URL expression or path is converted into a first local path based on a predetermined directory on the client terminal, and a path of the location of the HTML data is converted to a second path based on the predetermined directory. Convert to local path,
As the demo application, an HTML file composed of the HTML data is output to a location indicated by the second local path on the client terminal, and each file including a resource referred to by the HTML data is output on the client terminal. A demo application generation program that outputs or copies to a location indicated by the corresponding first local path.

Images