USPatent applicationPatented

Method to reduce input parameter interface error and inconsistency for servlets

Granted 3 Jan 2006 · 2 office actions

Assignee: International Business Machines

Law firm: Law firm · Log in to unlock

Attorney: Attorney · Log in to unlock

Inventors: Jin Li · Examiner: Mohammad Ali · AU 2167 · TC 2100

Life of the application

12 dated events
⤢ drag to zoom20022004200620082010201220142016201820202022ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

A GUI utility tool running on a web application development environment is presented that acts to eliminate inconsistency between a given HTML user input form description file and a corresponding servlet program file. The tool allows the user to specify an HTML file. The tool may then parse the HTML file to discover input parameters and generate Java servlet program code to receive the input parameters.

Description

6 parts
›FIELD OF THE INVENTION

The present invention relates to generation of servlet programs that correspond to user input forms and, more particularly, to reducing input parameter interface error.

›BACKGROUND OF THE INVENTION

Although the Internet and, more specifically, the world wide web (or just “the web”) is a very useful tool for distributing information, the web may be used as an information gathering tool as well. A typical server-side information gathering session involves a web server and an application server. In a representative information gathering session, a Hyper-Text Markup Language (HTML) form is served by the web server to gather user input. Once received by a web server, the user input may be submitted to a common gateway interface (CGI) script or a servlet program running on the application server. In the case where a servlet program receives the input, the servlet program must parse the input into input parameters and extract the value of each input parameter.

For example, an input parameter named “employeeID” is defined in the following HTML code and a portion of Java code (from a corresponding servlet program) is provided to use the input parameter.

It is known that the name of the input parameter must be the same in both the HTML code and the Java code. Taken together, multiple input parameters serve as an interface (called an “input parameter interface” herein) between an HTML input file and a corresponding servlet program file. If any changes are to be made, both files need to be updated and, it is then hoped that both the HTML input file and the servlet program are free of spelling errors, etc. Furthermore, it is typical for one person, a web developer, to develop the HTML file, and another person, a Java coder, to develop the servlet program. This separation of development roles can lead to synchronization and consistency problems.

›SUMMARY OF THE INVENTION

A utility development tool is proposed to solve synchronization and consistency problems between HTML files and corresponding servlet programs. A servlet program developer may use this utility development tool to automatically parse the input parameters from an HTML file. The servlet developer may then select input parameters of interest for the servlet program and, thereby, allow the tool to automatically generate appropriate servlet program code for retrieving the input parameter value from the selected input parameters. In addition, this tool can use timestamps on the HTML and servlet program files to generate notifications instructing the servlet developer to synchronize the input parameter interface.

In accordance with an aspect of the present invention there is provided a method of generating servlet program code, to reduce input parameter interface error, including receiving a form description file, automatically parsing the form description file to discover input parameters and automatically generating the servlet program code to receive the input parameters. In a further aspect of the present invention, there is provided a software medium that permits a general purpose computer to carry out this method.

In accordance with another aspect of the present invention there is provided a method of synchronizing files including determining a first value for a time stamp on a form description file, determining a second value for a time stamp on a servlet program file, comparing the first value to the second value and, if the comparing indicates that the form description file was edited more recently than the servlet program file, generating an alarm. In a further aspect of the present invention, there is provided a software medium that permits a general purpose computer to carry out this method.

Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

›BRIEF DESCRIPTION OF THE DRAWINGS

In the figures which illustrate example embodiments of this invention:

FIG. 1 illustrates a communications network for use with an embodiment of the present invention;

FIG. 2 illustrates, in a flow diagram, method steps followed by a graphical user interface (GUI) utility tool during a servlet program file generation session in an embodiment of the invention;

FIG. 3 illustrates, in a flow diagram, method steps followed by the GUI utility tool while parsing a form description file in an embodiment of the invention;

FIG. 4 illustrates an exemplary servlet program file specification page presented in an embodiment of the present invention;

FIG. 5 illustrates an exemplary form description file specification page presented in an embodiment of the present invention; and

FIG. 6 illustrates, in a flow diagram, method steps followed to allow a user to maintain synchronization between a servlet program file and a form description file in an embodiment of the invention.

›DETAILED DESCRIPTION · 1 of 2

FIG. 1 illustrates a communications network 100 including an application server 102 , a web server 106 and a development environment 112 all connected to a local area data network 104 . The web server 106 is also connected to a wide area data network that is connected to a personal computer 110 . The development environment 112 may be, for instance, VisualAge™ for Java™ marketed by IBM Corporation of Armonk, N.Y., and may be used for producing both web pages to be served from the web server 106 and servlet program files that run on the application server 102 .

In overview, a graphical user interface (GUI) utility tool 111 , running on the development environment 112 , automatically parses an HTML file, which is to be served, for instance, to the personal computer 110 by the web server 106 , for input parameters. The GUI utility tool 111 then generates servlet program code to receive the parsed input parameters. The servlet program code is subsequently executed on the application server 102 . Generation of servlet program code in this way acts to eliminate errors in the manual coding process and guarantee input parameter interface consistency between the HTML files and corresponding servlet program files. The use of a timestamp on files, to produce user notifications to re-generate the servlet program code in the servlet, minimizes the chance that the HTML files and corresponding servlet program files become unsynchronized.

In operation, the GUI utility tool 111 is run on the development environment 112 by a user of the development environment 112 . Steps of a servlet program file generation method are illustrated in FIG. 2 . The GUI utility tool 111 initially presents a servlet program file specification page to the user (step 202 ). An example of such a page is illustrated in FIG. 4 as servlet program file specification page 400 . A servlet program file name is then received from the user by the GUI utility tool 111 (step 204 ). The servlet program file specified by the user may be an existing file or a file that is to be generated by the GUI utility tool 111 . The GUI utility tool 111 then presents an HTML file specification page to the user (step 206 ). An example of such a page is illustrated in FIG. 5 as a form description file specification page 500 . An HTML file name is then received from the user by the GUI utility tool 111 (step 208 ). The GUI utility tool 111 then parses the HTML file specified by the user to identify input parameters (step 210 ). A detailed examination of the steps involved in parsing the HTML file is described hereinafter in conjunction with FIG. 3 . In response to a signal received from the user, for instance, the pushing of a “Finish” button 502 on the form description file specification page 500 , the input parameters that were parsed in step 210 are used to generate a servlet program file (step 212 ). The generated servlet program file is then written (step 214 ) to a file with the name received in step 204 .

FIG. 3 illustrates the sub-steps which are involved in step 210 . The GUI utility tool 111 begins parsing the HTML file, as illustrated in FIG. 3 , by opening the HTML file (step 302 ) that was specified in step 208 ( FIG. 2 ). Each tag in the HTML file is read sequentially (step 304 ). If the tag in question is not the last tag in the HTML file, it is determined whether the tag identifies an input parameter (step 308 ). A tag that identifies an input parameter may, for instance, read as follows:

<INPUT TYPE=“text” NAME=“Employee ID:” ID=“employeeID” SIZE=“8”>

If the tag in question identifies an input parameter, the name of the input parameter (employeeID in the above example) is extracted (step 310 ) and the next tag is read (step 304 ). However, if the tag in question does not identify an input parameter, no action is taken in relation to the tag and the next tag is read (step 304 ). If the tag in question is the last tag in the file, likely recognised as “</html>”, or the end of the file is reached (step 306 ), it is then determined whether any input parameters have been extracted (step 312 ). If input parameters have been extracted, the input parameter names are used to assign names for use in servlet program code (servlet program field name, servlet program constant name) (step 314 ) and these names are presented to the user (step 316 ). This presentation to the user allows the user to alter the names if desired. These alterations, if any, are received (step 318 ) before the parsing operation s considered complete. Once parsing is considered complete, the GUI utility tool 111 generates the servlet program code (step 212 , FIG. 2 ).

As shown in the form description file specification page 500 ( FIG. 5 ), two input parameters, namely “id” and “password”, have been parsed from the specified HTML file (Mylnput.html). A servlet program field name (e.g., id — , password — ) has been automatically chosen by the GUI utility tool 111 , corresponding to each input parameter. A servlet program constant name has also been assigned, by the GUI utility tool 111 , to each servlet program field name. Although names for the servlet program fields and constants are initially assigned by the GUI utility tool 111 , the structure of the form description file specification page 500 may be arranged, as shown in FIG. 5 , to allow the user to modify the naming.

After generation of the servlet code to capture input parameters, a user may generate code to operate upon, or otherwise analyze, the parameter values. This may not be necessary if the servlet code to capture input parameters is merely being regenerated to synchronize with an HTML file that has changed. However, in the regeneration case, the remainder of the servlet code should be changed to reflect changes in the input parameters capturing servlet code.

As the generated servlet program file is saved in step 214 , a time stamp may be included, indicating, for instance, a date and time at which a servlet program file was generated. Similarly, whatever tool is used to make amendments to the HTML file may include a time stamp indicating a date and time at which the HTML file was amended. A secondary application, or a function of the GUI utility tool 111 , may be devised to allow a user to maintain synchronization between a servlet program file and a corresponding HTML file.

›DETAILED DESCRIPTION · 2 of 2

FIG. 6 illustrates steps of a method that allows a user to maintain synchronization. Initially, a given servlet program file is associated with a corresponding HTML file (step 602 ), i.e., the HTML file from which the given servlet program file was (in part) generated. Monitoring the time stamps requires that this synchronization maintenance application read the given servlet program file time stamp (step 604 ) and the time stamp of the corresponding HTML file (step 606 ). The time stamps may then be compared (step 608 ). If the time stamp on the HTML file is more recent than the time stamp of the given servlet program file, an alarm may be generated (step 610 ). This alarm suggests to the user that the given servlet program file, for which the alarm is raised, may not be synchronized with the corresponding HTML file.

Thus far described, the invention relies on input from a user of the development environment 112 ( FIG. 1 ) via a GUI. However, the utility tool 111 may be arranged to act on an input file that lists a servlet program file name (for a new or existing servlet program file) and an HTML file name (for an existing HTML file).

As will be apparent to a person skilled in the art, one suitable language for the servlet program code is Java.

Furthermore, the language used for the form description files may be other than HTML, such as the Extensible Markup Language (XML).

Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.

Claims as granted

1 claim

Log in to read the claims of this application.

Log in to unlock

Classifications

12 codes
IPC · International Patent Classification
Section G — Physics
  • G06F17/27
  • G06F9/44
  • G06F7/00
  • G06F12/14
  • G06F17/30
  • G06F11/30
Section H — Electricity
  • H04L9/32
  • H04L29/08
USPC · US Patent Classification
707/102707/10715/513715/762

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomJan 2002Jul 2002Jan 2003Jul 2003Jan 2004Jul 2004Jan 2005Jul 2005Jan 2006USPTOApplicantNon-final rejectionResponse after non-finalFinal rejectionNotice of allowance
USPTOApplicanthover for detail · click to open
Pendency
3.8 y
1,383 days filing → grant
Office actions
2
non-final + final
Responses
2
1 RCE
Interviews
1
examiner interview summaries
Examiner
Mohammad Ali
art unit 2167 · TC 2100
Citations: 3 back · 0 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom20022004200620082010201220142016201820202022Owner 1
Titlehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock