JP6212657B2 - Development support system - Google Patents

Description

  The present invention relates to a Web application development technique, and more particularly to a technique that is effective when applied to a development support system that supports the development of a Web application that displays a screen corresponding to a multi-device.

  In recent years, for example, business utilization of so-called smart devices such as tablet terminals and smartphones has become full-fledged, and there is a tendency to increase the number of medium- and large-scale system development projects that are linked with a company's core system. Under these circumstances, the requirements of user companies have become complex, and the level of development difficulty has become higher for developers such as IT vendors. Therefore, it is important to improve the efficiency of development and improve productivity. .

  In this regard, for example, it is effective to promote common parts / general parts in development products such as source code and reuse of parts during development. Furthermore, it is also effective to reduce individual development portions for each device and platform by supporting multi-devices and multi-platforms (hereinafter sometimes simply referred to as “multi-devices”).

  In relation to the technology for making reusable components compatible with multi-devices, for example, Japanese Unexamined Patent Application Publication No. 2013-235387 (Patent Document 1) describes the appearance, attributes, and control of controls for displaying input / output items. A Web server system that dynamically changes a user interface including processing and the like without changing a source code according to a device is described. The system includes, for example, a device acquisition unit that acquires information related to a device type of the client terminal based on a request from the client terminal, and a client terminal acquired by the device acquisition unit for a part object included in the source code. Response that generates HTML data to display the corresponding control on the screen of the client terminal, based on the adjustment contents when displaying the control, implemented in the upper class of the inheritance source of the part object according to the device type And a processing unit.

JP 2013-235387 A

  For example, by using a technique as described in Patent Document 1, it is possible to reuse a part (part object) when developing a Web application and to support multiple devices with one source code. Become.

  However, in fact, even if it is said that multiple devices are supported by one source code, it may be necessary to write processing for each device by using, for example, an if statement in the source code. In addition, when a new device is added, it is difficult for a screen developer to fully support multiple devices with a single source code, such as having to add processing to the source code.

  Also, as a multi-device support, for example, even when the user interface can be switched according to the screen size of the device, the size, display format, arrangement, etc. of controls and parts displayed on a screen can actually be changed Therefore, it is difficult to make a change with a transition of a plurality of screens.

  For example, the screen size of a smartphone is smaller than that of a PC (Personal Computer) or tablet terminal, and the amount of information that can be displayed is limited. Therefore, for example, with respect to list display of menus and the like, a list display is always performed on a single screen on a PC or tablet terminal, whereas a smartphone normally displays only icons or the like for instructing menu display. In some cases, an interface may be employed in which a menu list is displayed as a separate screen when a menu display is instructed via the icon or the like. In these cases, it is difficult for the conventional technology to deal with each pattern with one source code. Therefore, when screen development is performed using reusable components, a mechanism that enables multi-device support with a single source code is desired even if the devices are different.

  On the other hand, when developing web application screens using reusable parts, what parts exist, which are available, and source code to use the target parts There is a problem that it is difficult to grasp how to implement the above. When multiple development projects coexist, the parts that can be used for each project may be different, and even within the same project, the parts that can be used for each subsystem or application may differ from the viewpoint of screen design uniformity. . In particular, since the parts here are related to the components of the screen, if the appearance and operability of the available parts cannot be grasped visually as a list, the efficiency in selecting and determining the parts is large. To reduce.

  For example, a list of available parts can be provided to the developer by preparing a manual or specifications, but static information in the manual etc. is sufficient for the appearance and operability of the parts. It is difficult to grasp and the searchability of parts is also reduced. Furthermore, maintainability also deteriorates because it is necessary to update manuals and specifications whenever parts are corrected or new parts are added.

  Accordingly, an object of the present invention is to make it easy for a developer to visually list a list of available parts in a mechanism that enables screen development related to a multi-device compatible Web application by reusing the componentized parts. The purpose is to provide a development support system that can be grasped.

  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 development support system according to a representative embodiment of the present invention supports a screen development of a Web application that receives a request from a client terminal and responds with a processing result screen corresponding to the device type of the client terminal. However, it has the following characteristics.

  That is, the development support system includes a template that is stored in a predetermined folder, includes a combination of one or more screen parts, and defines the appearance when each screen part is displayed on the screen for each type of device. Two or more components, a component management controller that receives a request to display a list of available components that can be used for screen development of the Web application via the developer terminal, and an instruction from the component management controller And a component management model for obtaining list information of the available components from the components stored in the folder. Further, based on an instruction from the component management controller, each available component acquired by the component management model is listed according to an appearance defined by the template corresponding to the device type specified from the developer terminal. It has a component list view that creates a display screen and displays it on the developer terminal.

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

  In other words, according to a typical embodiment of the present invention, a list of available components is displayed in a mechanism that enables screen development related to a multi-device compatible Web application by reusing componentized components. Developers can easily grasp visually.

It is the figure which showed the outline | summary about the structural example of the Web server system which is Embodiment 1 of this invention. (A), (b) is the figure which showed the outline | summary about the example of the difference in the layout for every device in Embodiment 1 of this invention. (A), (b) is the figure which showed the outline | summary about the other example of the difference in the layout for every device in Embodiment 1 of this invention. (A), (b) is the figure which showed the outline | summary about the example of the difference in the component display for every device in Embodiment 1 of this invention. (A), (b) is the figure which showed the outline | summary about the other example of the difference in the component display for every device in Embodiment 1 of this invention. It is the figure which showed the outline | summary about the example of the content of designation | designated in the edit view in Embodiment 1 of this invention, and the process flow at the time of the screen display accompanying this. It is the figure which showed the outline | summary about the structural example of the development assistance system which is Embodiment 2 of this invention. It is the figure which showed the outline | summary about the example of the list display screen of the component displayed on the screen of the developer terminal in Embodiment 2 of this invention. It is the figure shown about the example of the sample code displayed on the screen of the developer terminal in Embodiment 2 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.

(Embodiment 1)
<System configuration>
FIG. 1 is a diagram showing an outline of a configuration example of a Web server system according to the first embodiment of the present invention. The Web server system 100 according to the first embodiment of the present invention converts the screen parts into components and has a list of components 190, and the layout 180 includes a layout pattern including one or more screen areas in which the components 190 are arranged. Has a list. Each layout 180 and each component 190 has a template created so as to output a screen optimized for each device, and the Web server system 100 is optimized for each device based on these templates. Automatic screen output.

  The Web server system 100 is a server system composed of, for example, a server device or a virtual server built on a cloud computing service. For example, an OS (Operating System) not shown, a Web server program 110, a language processing system 120, As a software that runs on or uses middleware or infrastructure such as the framework 130, a controller 140, model 150, edit view 160, component view 170, developed and implemented by an MVC (Model View Controller) model, Each unit (module) such as a layout 180 and a component 190 is included.

  As the Web server program 110, for example, an Apache (registered trademark) HTTP Server or the like generally used in a Web server can be used as appropriate. Further, as the language processing system 120 and the framework 130 which are the basis of an application system running on the Web server program 110, for example, a script language such as PHP used for creating a dynamic Web page, and PHP are used. A mounted Zend Framework or the like can be used as appropriate.

  The controller 140 has a function as a controller (C) in the MVC model, receives a request from a web browser or the like (not shown) on the client terminal 200, makes a data operation request to the model 150, and acquires data. Or requesting the edit view 160 to display a screen. The model 150 has a function as a model (M) in the MVC model, and has a function of operating and acquiring data by executing business logic. The business logic (BL) may be executed by making a request to another BL server 300 having a database, for example.

  The edit view 160 and the component view 170 have a function as a view (V) in the MVC model, and have a function of generating and displaying a screen based on the data of the model 150. The edit view 160 has a function for configuring the screen. As will be described later, the edit view 160 designates a layout 180 to be used on the screen and calls and sets a component 190 arranged in an area displayed by the layout 180. The component view 170 performs rendering based on the information of the layout 180 and the component 190 to create HTML (HyperText Markup Language) data, and outputs the data to the client terminal 200.

  At this time, as described later, the component view 170 processes a Web template for screen display set for the layout 180 and the component 190 according to the device of the client terminal 200 by the template engine 171, thereby Perform screen output optimized for the target device.

  As shown in the figure, for each type of client terminal 200 (PC, smartphone (smartphone), tablet terminal), the web templates are for the layout 180, respectively, a template (for PC) 181p, a template (for smartphone) 181s, As for the template (for tablet) 181t (which may be collectively referred to as the template 181) and the component 190, template (for PC) 191p, template (for smartphone) 191s, template (for tablet), respectively 191t (these may be collectively referred to as a template 191). In the example of FIG. 1, templates 181 and 191 are prepared separately for PCs, smartphones, and tablet terminals. However, the present invention is not limited to this. The browser may have a different device.

  The template engine 171 has a function of creating an actual screen based on the design and appearance content defined in the Web templates such as the templates 181 and 191. As the template engine 171, for example, a general template engine such as Smarty mainly used in PHP can be used as appropriate.

  The controller 140 and the component view 170 can be provided for general use as the Web server system 100. Further, the layout 180 and the component 190 (including the templates 181 and 191) as screen parts are reused those created in other development projects, or those created in advance in the target development project are used. be able to. As the model 150, a model 150 separately created in a target development project or the like can be used. On the other hand, the edit view 160 is created as a source code by the screen developer. However, since the difference for each device is absorbed by the templates 181 and 191 (and the template engine 171), the screen developer has the difference for each device. It is not necessary to be aware of

<Layout and components>
FIG. 2 is a diagram showing an outline of an example of a layout difference for each device in the present embodiment. The layout refers to the layout pattern of the entire screen divided into one or more areas. In FIG. 2A, the layout on the tablet terminal, and in FIG. 2B, the smartphone. Each of the layout examples is shown.

  In the example of FIG. 2, a case where “list, detailed layout” is selected as the layout 180 is shown. In addition to the header area (header areas 401 and 411) and the footer area (footer areas 404 and 414), a plurality of items are displayed. A layout having a list area (list areas 402 and 412) for displaying a list of items and a content area (content areas 403 and 413) for displaying detailed contents when a specific item is selected from the list area is shown. Yes.

  As shown in the figure, in the layout of FIG. 2A, all four areas are arranged in one screen. On the other hand, in the layout of FIG. 2B, when a specific item is selected from the list area 412 while the list area 412 is displayed on the left screen, the screen changes to the right screen and the list area 412 is displayed. Instead, the content area 413 for displaying the selected item is displayed. Such a difference for each device in the same layout 180 is defined in the template 181 (in this case, the template (for tablet) 181t and the template (for smartphone) 181s), as described above, and the template engine 171 of the component view 170 Is reflected on the actual screen.

  In this way, the layout 180 and the template 181 absorb and conceal the differences for each device not only in the parts and control units displayed on the screen, but also in the layout of the entire screen (including those with screen transitions). To do. Thus, even if the device has a layout with screen transition, the edit view 160 can be developed without being aware of the device.

  FIG. 3 is a diagram showing an outline of another example of a layout difference for each device in the present embodiment. Similar to FIG. 2, FIG. 3A shows an example of a layout on a tablet terminal, and FIG. 3B shows an example of a layout on a smartphone. In the example of FIG. 3, a case where “search condition, result display type layout” is selected as the layout 180 is shown. In addition to the header area (header areas 401 and 411) and the footer area (footer areas 404 and 414), A search condition area (search condition area 405, 415) for displaying a part or the like for inputting and specifying a search condition, and a search result area (search result area 406, 416) for displaying a search result based on the search condition A layout having

  For example, by changing the layout 180 specified in the edit view 160 so that the arrangement of the areas in FIGS. 3A and 2A is different, the design of each area can be performed by the template engine 171 of the component view 170. The appearance can be switched automatically.

  FIG. 4 is a diagram showing an outline of an example of a difference in component display for each device in the present embodiment. As in FIG. 2, FIG. 4A shows an example of a layout on a tablet terminal, and FIG. 4B shows an example of a layout on a smartphone. The “list, details” shown in the example of FIG. In the “type layout”, the “menu” component 190 is displayed in the header areas 401 and 411.

  As shown in the figure, in the layout of the tablet terminal of FIG. 4A, four menu buttons are displayed side by side in the header area 401. On the other hand, in the smartphone layout of FIG. 4B, only the icon for displaying the menu is displayed in the header area 411 on the left screen, and when this icon is tapped, the screen transitions to the right screen, and the header area 411 is expanded (header area 411 ′), indicating that menu buttons are displayed vertically in this area. Similar to the layout 180, such a difference for each device in the same component 190 is defined in the template 191 (in this case, the template (for tablet) 191t and the template (for smartphone) 191s). Reflected on the actual screen by the template engine 171.

  The component 190 in the present embodiment is not limited to a single screen part or control. As shown in the figure, the component 190 is a combination or combination of a plurality of parts and controls (four menu buttons in the example of FIG. 4). It may be configured.

  FIG. 5 is a diagram showing an outline of another example of the difference in component display for each device in the present embodiment. Similar to FIG. 3, FIG. 5A shows an example of layout on a tablet terminal, and FIG. 5B shows an example of layout on a smartphone. In the “result display type layout”, the “search result list” component 190 is displayed in the search result areas 406 and 416. As illustrated, in the layout of the tablet terminal in FIG. 5A, a search result list is displayed in the search result area 406 in a table format. On the other hand, the layout of the smartphone in FIG. 5B shows that the search result list is displayed vertically in a list format in the search result area 416 of the screen on the right side after the transition.

<Process flow>
FIG. 6 is a diagram showing an overview of the specification content in the edit view 160 and an example of the flow of processing at the time of screen display associated therewith. As described above, the screen developer creates an edit view 160 that performs the following processing as source code. In that, the layout developer 180 specifies the layout 180 and the component 190 without being conscious of the differences between devices. Just place and set. The screen display optimized for each device is dynamically performed by the component view 170 (and the template engine 171) at the time of execution based on the contents defined in the templates 181 and 191.

  In the edit view 160, first, a layout 180 used for screen display is acquired from a list of layouts 180 created in advance (S01). At this point, no component 190 that should display anything has been placed in each area set in the layout 180. Next, one or more components 190 arranged in the layout 180 acquired in step S01 are acquired from the list of components 190 created in advance (S02). At this point, the component 190 has not been set to data to be displayed.

  Thereafter, the data acquired from the model 150 is set as data to be displayed for each component 190 acquired in step S190 (S03). Note that data acquisition by the model 150 is executed by an instruction via the controller 140. Next, each component 190 for which data is set is designated so as to be arranged in an appropriate area in the layout 180 acquired in step S01 (S04). Then, the layout 180 designating the arrangement position of each component 190 is transferred to the component view 170 to instruct screen drawing (S05).

  At this time, information related to the device type of the client terminal 200 is also passed to the component view 170 (or the component view 170 itself acquires from the content of the request message). Information related to the type of device can be acquired by a known technique such as acquiring from the User-Agent header of the request message from the client terminal 200, for example. Here, it is assumed that the information related to the device type includes, for example, information such as the OS, the Web browser, and its version in addition to the device type.

  In the component view 170, templates 181 and 191 corresponding to the device type are acquired for the passed layout 180 and each component 190, and screen drawing including data is performed according to the design defined in the template. For example, for each component 190, a template (for smartphone) 191s corresponding to the type of device (smartphone in the example of FIG. 6) is acquired, and the component 190 is included by including data based on the design defined therein. Screen drawing is performed (in the example of FIG. 6, a list of search results is displayed). As for the layout 180, the template 181s is acquired, and each area is drawn based on the design defined therein, and each component 190 drawn on the screen is placed at the position of the designated area (see FIG. In the example of FIG. 6, a list display of search results is arranged in the search result area 416).

  As described above, according to the Web server system 100 according to the first embodiment of the present invention, the screen parts are converted into components, and the layout 180 pattern including one or more areas in which the components 190 are arranged is displayed. Have. Each layout 180 and each component 190 have templates 181 and 191 created so as to output screens optimized for each device. The Web server system 100 processes these templates. A component view 170 having a template engine 171 is provided.

  As a result, the screen layout and components are converted into parts, and by calling these in the source code of the edit view 160, it is possible to dynamically perform screen display optimized according to the device. That is, the screen developer can create the source code of the edit view 160 without being conscious of the difference between devices. Furthermore, by separating the functions for controlling the processing and behavior of data in the layout 180 and the component 190 from the design (HTML, CSS (Cascading Style Sheets), etc.) defined by the templates 181, 191, the development results by the designer Objects can be easily captured as screen parts.

(Embodiment 2)
In the first embodiment described above, the screen developer can perform screen development by calling the component 190 converted into a part from the source code of the edit view 160. However, what kind of components 190 are present in the first place, which of them are available, and how to implement them on the source code in order to use the target components 190 are understood. hard.

  Therefore, the development support system according to the second embodiment of the present invention enables the screen developer to visually grasp the list of components 190 that can be used by the screen developer and the actual screen display examples. Provides component management functions. Also, by providing an implementation example (sample code) on the source code, the development load of the source code can be reduced. Specifically, a web application that displays a list of components 190 that can be used by the screen developer is operated on the web server system 100 using the web server system 100 according to the first embodiment. Realized by mounting as an application.

<System configuration>
FIG. 7 is a diagram showing an outline of a configuration example of the development support system according to the second embodiment of the present invention. As described above, the development support system 101 of the present embodiment is a development environment configured based on the Web server system 100 shown in FIG. 1 in the first embodiment, such as a PC used by a screen developer. This is a system that provides a component management function for the developer terminal 201 to actually display a list of available components 190 on the screen.

  The Web server program 110, language processing system 120, and framework 130 in the development support system 101 are the same as those in the Web server system 100 shown in FIG.

  The component management controller 141 has a function as a controller (C) in the MVC model. In this embodiment, the component management controller 141 receives a request from a web browser (not shown) on the developer terminal 201 and receives a component management model 151 described later. From this, information on the list of components 190 that can be used by the developer who uses the developer terminal 201 is acquired. Further, the component list view 161 described later is requested to actually display the acquired list of components 190 on the screen.

  The component management model 151 has a function as a model (M) in the MVC model. In this embodiment, the component management model 151 acquires information on a list of available components 190 and responds to the component management controller 141. In order to realize this, in the present embodiment, it is assumed that all the components 190 (actually, files in which the source code of the component 190 is recorded) are arranged in a predetermined folder or directory. The component management model 151 can grasp various types of information related to each component 190 by referring to the contents of the source code of each component 190 existing in the folder or the like. For example, in the source code of a component 190, by describing detailed information and the like related to the component 190 as meta information by annotation according to a predetermined rule, the information can be read and grasped.

  The component list view 161 has a function as a view (V) in the MVC model, and has a function of generating and displaying a screen based on data of the component management model 151. That is, in the present embodiment, the list is actually displayed on the screen based on the information of the available components 190 acquired by the component management model 151.

  In the first embodiment, the layout 180 is optimized by the device of the client terminal 200 that displays the screen including the component 190. However, in the present embodiment, the device 190 is displayed when the component 190 is displayed as a list. The layout is uniformly fixed without considering the difference in layout. In this embodiment, a portable terminal such as a tablet terminal or a smartphone is rarely used as the developer terminal 201 for performing the phase of development and creation of source code, and a PC is mainly used. It is possible.

  Therefore, the example of FIG. 7 has a configuration that does not have the list of layouts 180 in the example of FIG. 1 of the first embodiment. On the other hand, as a method for uniformly fixing the display on the screen of the developer terminal 201, for example, only the template (for PC) 181p is used after having the configuration having the layout 180 in the Web server system 100 of FIG. You may do it.

  In addition, in order to actually display each component 190, in the present embodiment, a sample code 192 for display including dummy sample data settings used for display is prepared for each component 190. The component list view 161 can call the component 190 by using this sample code 192.

  The actual screen display of the component 190 is displayed by the template engine 171 calling and processing a template created to perform screen output optimized for each device, as in the case of the first embodiment. To do. As will be described later, by enabling the designation of the device type on the screen displayed on the developer terminal 201, the screen display of the component 190 is switched using a template corresponding to the designated device. As a result, on the same developer terminal 201, the screen display can be dynamically switched for each device, and the appearance of the component 190 can be confirmed.

  In the present embodiment, an example in which the development support system 101 that is the development environment of the web application is implemented independently of the web server system 100 illustrated in FIG. 1 of the first embodiment that is the execution environment. However, it is also possible to adopt a configuration in which these coexist as the same server system.

<Screen example>
FIG. 8 is a diagram showing an outline of an example of a list display screen of components 190 displayed on the screen of the developer terminal 201 by the development support system 101. In the upper part of the screen, a target device can be selected as a format for displaying each component 190 (in the example of FIG. 8, “tablet” is selected). Regardless of the actual device type of the developer terminal 201, the device is emulated by displaying each component 190 in a display format optimized for the device selected here. In order to realize this, for example, when a request to display a list of components 190 is transmitted from the developer terminal 201 to the development support system 101, information for specifying a device included in the request is selected as the device selected here. To do so.

  In the left part of the screen, conditions for narrowing down the components 190 can be specified. For example, it is possible to narrow down by a category set for each component 190, or narrow down by a module or application that can use (or use) each component 190. In the example of FIG. 8, it is specified to narrow down by “module”, and a list of components 190 that can be used by modules and applications with check marks is displayed on the right side of the screen. Information about which component 190 each module or application can use can be set and registered separately for each module or application in a setting file, for example.

  On the right side of the screen, for each component 190, in addition to the component name, as a detailed information of the component 190, a function overview, information on main API (Application Programming Interface), and the like are displayed (the detailed information is selectively hidden). Display). Such information and other attribute information such as the category of the component 190 are described as meta information by an annotation in accordance with a predetermined rule by the developer in the source code of each component 190, for example. Thus, the component management model 151 can dynamically acquire these pieces of information by referring to the source code of each component 190.

  In addition to the above information, the actual display image on the target device is also displayed for each component 190. On the right side of the display image, buttons that can individually switch the display target device for each component 190 are provided. As described above, the display image displayed here is implemented by, for example, the sample code 192 for displaying the component 190 including the setting of dummy sample data for display.

  In this way, by displaying a list of available components 190 together with their actual display images, the screen developer can efficiently determine the components 190 that are actually arranged on the screen.

  Once the component 190 to be placed on the screen is determined, the screen developer must actually write the code that calls it in the application source code. In order to enable this to be performed efficiently, the present embodiment further provides detailed specification information on the API of each component 190 and sample code 192 that can be directly used when describing the source code. It is said. These can be displayed, for example, when the developer presses the “API” button and the “src” button arranged in the column for displaying the function outline of the component 190 in the example of FIG.

  For example, on the screen displaying the API specification information, the function summary, the class hierarchy, a list of specification information such as parameters for available APIs (methods), etc. are displayed for the target component 190. As described above, the detailed information can be dynamically acquired by the component management model 151 by describing the detailed information as an annotation in the source code of the component 190.

  FIG. 9 is a diagram illustrating an example of the sample code 192 displayed on the screen of the developer terminal 201 by the development support system 101. Here, in addition to calling the component 190, dummy sample data is set for the component 190 (9th to 15th lines). By referring to this, the screen developer can grasp a specific mounting method and usage method of the target component 190 on the source code. Furthermore, by copying and pasting the sample code 192 directly into the source code of the actual application and modifying necessary parts such as display data and other setting parts, the development load of the source code is greatly reduced. be able to.

  As described above, the sample code 192 is also used to actually display each component 190 on the component 190 list display screen shown in FIG.

  As described above, according to the development support system 101 according to the second embodiment of the present invention, a list of components 190 that can be used by the screen developer and an actual screen display example are visually displayed by the screen developer. It is possible to realize a component management function that can be grasped easily. In addition, by providing detailed information of each component 190 and an implementation example (sample code) on the source code, the development load of the source code of the application can be greatly reduced.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiments. However, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention. Needless to say. For example, the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. . In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

  The present invention can be used in a development support system that supports development of a Web application that displays a screen corresponding to a multi-device.

DESCRIPTION OF SYMBOLS 100 ... Web server system, 101 ... Development support system, 110 ... Web server program, 120 ... Language processing system, 130 ... Framework, 140 ... Controller, 141 ... Component management controller, 150 ... Model, 151 ... Component management model, 160 ... Edit view, 161 ... Component list view, 170 ... Component view, 171 ... Template engine, 180 ... Layout, 181p ... Template (for PC), 181s ... Template (for smartphone), 181t ... Template (for tablet), 190 ... Component, 191p ... Template (for PC), 191s ... Template (for smartphone), 191t ... Template (for tablet),
200: Client terminal, 201: Developer terminal,
300 ... BL server,
401 ... header area, 402 ... list area, 403 ... content area, 404 ... footer area, 405 ... search condition area, 406 ... search result area, 411, 411 '... header area, 412 ... list area, 413 ... content area, 414 ... Footer area, 415 ... Search condition area, 416 ... Search result area

Claims (4)

A development support system that supports screen development of a Web application that receives a request from a client terminal and responds with a processing result screen corresponding to the device type of the client terminal,
One or more components having a template that is stored in a predetermined folder and includes a combination of one or more screen parts, and defines the appearance when each screen part is displayed on the screen for each type of the device;
A component management controller that accepts a request to display a list of available components that can be used by the developer for screen development of the Web application via the developer terminal;
Based on an instruction from the component management controller, a component management model that acquires list information of the available components from the components stored in the folder;
Based on an instruction from the component management controller, for each available component acquired by the component management model, a list display screen with an appearance defined by the template corresponding to the type of device specified from the developer terminal And a component list view to be displayed on the developer terminal. The development support system according to claim 1,
In the predetermined folder, sample codes for using each component in the Web application are recorded.
The component list view is a development support system that creates the appearance of each available component by executing the corresponding sample code when creating the list display screen. The development support system according to claim 2,
The component list view is a development support system for causing the developer terminal to display the sample code corresponding to each available component displayed on the list display screen. The development support system according to claim 1,
Detailed information is described in annotations in the source code of each component,
The component list view is a development in which detailed information related to each available component displayed on the list display screen is acquired from the description of the annotation of the source code of the available component and displayed on the developer terminal. Support system.

Images