A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The disclosure relates generally to project management. The disclosure relates more specifically to techniques for terminating a client-side web browser script generated by a web server when an abnormal condition is encountered.
Web programming languages, such as PHP, provide an object-oriented based scripting language often used for the development of server-side web applications. Scripting languages allow a programmer to create web applications that may be interactively run over a network. The web applications developed using scripting languages allow dynamic HTML pages which can process user inputs and maintain persistent data using special objects, files, and interact with relational databases. PHP (server-side) and JavaScript (client-side) or equivalent open source scripting languages are generally viewed as improvements over HTML, which is generally limited to displaying static text and images. The advantages of using scripting languages are in the simplicity of designing and implementing dynamic web pages.
One disadvantage when using large interactive web applications developed using interpretable scripting languages is the difficulty in debugging the server-side script when programmed to exchange information with one or more web enabled clients. For example, an improperly executing or failed application on a web server may go undetected by the web browser enable client. In one common context, a client script executing in a client-side web browser may simply continue to display a web page without providing any notice to the user that a functional state of the web server has been compromised or lost.
In another more serious context, the scripted client application remains active and continues to generate erroneous objects and data which are locally cached awaiting retrieval and deletion by a web server. The erroneously accumulated objects and data may overwrite valid objects and data until the local resources of the client become exhausted or the client crashes resulting in lost data entries and possibly damaging other objects and data stored on the client.
The inability to determine the functional state of the web server is due to the lack of a defined JavaScript statement or function to terminate when an abnormal condition is encountered, as is available in server-side scripting and compiled languages. For example, PHP includes die( ) and exit( ) statements and compiled languages such as a C++ include abend( ) and other statements to gracefully terminate.
In an embodiment, a mechanism allows a web server to terminate processing of a dynamic web page executing on a client side web browser when an abnormal condition is encountered by the web server. In an embodiment, the approach herein can both capture the location of the abnormal condition on the web server and can gracefully terminate execution of the client-side script.
In an embodiment, a web enabled client receives browser executable code in the form of an interpretable script from a code executing on a web server. The code executing on the web server is executed within an exception handler to determine whether an abnormal condition has been encountered. If an abnormal condition has been encountered, the exception handler calls one or more global functions to generate and send a graceful termination script to the client-side browser executable code and terminate execution of the code on the web server.
In an embodiment, the generated client browser executable code is programmed in JavaScript.
In an embodiment, the exception handler is a global function programmed in PHP.
In an embodiment, the global function is configured to capture the abnormal condition for output on a display coupled to the web server.
In an embodiment, the displayed abnormal condition is one of; a filename, a code line number, a class, and a function which called the global function.
In the drawings:
In an embodiment, techniques provide graceful termination of an interpretable script code executing in a client browser window. Example embodiments are associated with a client-server based project schedule task management system. However, the approaches described herein are broadly available to other software development projects. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention.
In response to completion of a task assignment session, such as in response to a user selecting the “Finish” button on the task assignment editor 102 of
According to one embodiment, the task assignment editor 102 (
In response to completion of a project schedule session, such as in response to a user selecting the “Finish” button on the project schedule editor 202 of
According to one embodiment, the project schedule editor 202 (
In response to completion of a member schedule session, such as in response to a user selecting the “Finish” button on the member schedule editor 302 of
In member schedule editor 302, buttons (Add Details, Add Rows At Bottom, Add Rows Above, Add Rows Below, Delete, Update, and Finish) are positioned near the table, which are used to perform various respective operations. The “Finish” button completes the member schedule editor session and submits the task schedule information to be stored and maintained in the database. Except for the “Update” button and the “Add Rows At Bottom” button, the other buttons perform an operation on a task that is selected by selecting the checkbox in the row corresponding to the task. The “Add Details” button adds rows beneath a task so the member can add subtasks (a task one level lower) to a task to give more details of the task. “Add Rows Above” and “Add Rows Below” buttons add rows above and below the row corresponding to the selected task so the member can add more tasks to the schedule at the same level. The number of rows added is set by the “number of rows” menu selection that is next to the “Add Rows Below” button. The “Delete” button deletes the selected task. The “Delete” button also removes a task, and all lower level tasks associated with the task, from the member's schedule. The “Add Rows At Bottom” button adds one or more highest level rows to the bottom of the schedule where the number of rows added is set in the “number of rows” menu selection. The “Update” button updates all the upper level task schedules with the lower level task schedules and updates the display of the member schedule editor 302 to show the new dates.
The schedule information for a task includes the plan start and end dates and the actual start and end dates. The plan and actual dates can be set and modified for tasks in the member schedule editor 302. However, only the plan dates can be set for the project tasks in the project schedule editor 202 (
Generally, web servers 507 and 530 comprise the resources for the display and management of the editors. The web servers 507, 530 interact with databases 506, 536, respectively, to store, maintain, and manage task assignment and task schedule information, e.g., data 508, 538. The depiction of two web servers and two databases is for purposes of example. Thus, the number of web servers and databases used in a project schedule management system as described herein may vary from implementation to implementation. Web browsers on computer workstations 501, 502 access the resources on the web servers 507, 530 to display the editors. Project members or managers can access the editors over the network 500 (LAN or WAN). The project management system can be used to manage projects at different levels within an organization, e.g., at project, department, division, and organization levels.
Workstations 501, 502 are typically computer systems configured as illustrated by the computer system 3500 of
Web servers 507, 530 depict a typical web server, which is a combination of computer hardware and software that, using the appropriate protocols (e.g., Hypertext Transfer Protocol [HTTP] and Transmission Control Protocol/Internet Protocol [TCP/IP]), serves the files that form web pages (e.g., Hypertext Markup Language [HTML] or Extensible Markup Language [XML] files), to users, such as developers or managers at a workstation 501, 502. For a non-limiting example, an Apache web server, which contains modules for the execution of PHP scripts, may be used as the web server application for the web server 507 and 530. In general, the majority of information exchanged and managed during the development project life cycle is served by the web servers 507, 530 over the network 500. Furthermore, aspects of the techniques described herein may be implemented and executed on the web servers 507, 530, although practice of the invention is not limited to such an implementation. The techniques could also be implemented on any other processing system, such as workstations 501, 502 or a similarly configured computer system as illustrated in
Databases 506, 536 depict typical databases for storing data 508, 538 related to the development project, thus providing access to the information by authorized individuals at workstations 501, 502, through queries transmitted over the network 500. The type of data stored on databases 506, 536 is effectively limitless, wherein non-limiting examples include project initiation forms, member and project task schedules, specifications, software code, inspection reports, web page files, and document directories and indexes.
Network 500 depicts a conventional network, e.g., a packet-switched network, for facilitating the exchange of information between and among various connected components, such as workstations 501,502, web servers 507, 530, and databases 506, 536. The network 500 may be a Local Area Network (LAN), such as a conventional Ethernet, Fast Ethernet, a token ring, or a wireless LAN such as specified in 802.11a and 802.11b (developed by a working group of the Institute of Electrical and Electronics Engineers [IEEE]), which may be implemented within an enterprise. In addition, network 500 may also be a Wide Area Network (WAN), such as the Internet, for facilitating communication with remote users through a Virtual Private Network (VPN), or the network 500 may represent a combination of a LAN and a WAN. In addition, network 500 can be formed using a variety of different mediums, including but not limited electrical wire or cable, optical, or wireless connections.
The server processor 604 provides information to the client processor 602 to display the login web page (
HTTP/HTTPS GET Project/Dept/Division Home Page requests cause the server processor 604 to return to the client processor 602 a project home page associated with a department or division, respectively. The home page contains links (e.g., hyperlinks) for linking to and viewing the respective web page for the schedules, task assignment, and login to the editors.
HTTP/HTTPS GET current project directory/schedule.htm requests cause the server processor 604 to return to the client processor 602 a web page containing the project schedule for a current project, an example of which is depicted in
HTTP/HTTPS GET current project directory/taskAssignment.htm requests cause the server processor 604 to return to the client processor 602 a web page containing the task assignments of project tasks for the current project, an example of which is depicted in
HTTP/HTTPS GET project member directory/schedule.htm requests causes the server processor 604 to return to the client processor 602 a web page containing a project member's schedule for the current project, an example of which is depicted in
HTTP/HTTPS GET login.htm requests cause the server processor 604 to return to the client processor 602 a web page that allows a project member or manager to log on to one of the editors (project schedule, member schedule, task assignment). The member or manager enters information about the project, member name, and editor session type.
HTTP/HTTPS GET TaskAssignEditor.htm requests cause the server processor 604 to return to the client processor 602 a web page for the task assignment editor, which is used to assign tasks to the project members for the current project. A project manager requires access privileges to assign tasks to the project members before the server processor 604 returns the task assignment editor web page. This privilege is verified when the manager submits the information in the login web page (
HTTP/HTTPS GET ProjScheduleEditor.htm requests cause the server processor 604 to return to the client processor 602 a web page for the project schedule editor, which is used to create or update the project schedule for the current project. A project manager must have access privileges to create the project schedule before the server processor 604 returns the project schedule editor. This privilege is verified when the manager submits the information in the login web page (
HTTP/HTTPS GET MembScheduleEditor.htm requests cause the server processor 604 to return to the client processor 602 a web page for the member schedule editor, which is used to create or update a project member's schedule for the current project. According to one embodiment, the schedule editor displays only uncompleted tasks if the project member's schedule has been previously created. A project member must have privileges to create or edit the schedule before the server processor 604 returns this web page. This privilege is verified when the member submits the information in the login web page (
HTTP/HTTPS POST login.htm interface allow the client processor 602 to access and display the various editors (project schedule, member schedule, task assignment). This interface is called when the “Submit” button is selected from the web page corresponding to login.htm. The information entered in login.htm is passed to PostLogin.htm in the server processor 604. The PostLogin.htm uses the information to validate the member for the project, and to determine if the member has access privileges to the requested editor. If the information is invalid or the member does not have access privilege to the editor, then PostLogin.htm returns a message to the client processor 602 that the project member cannot access the requested editor. Otherwise, PostLogin.htm returns the web page corresponding to one of the editors, i.e., the web browser is redirected to the web page corresponding to the requested editor.
HTTP/HTTPS POST PostTaskAssign.htm allows the client processor 602 to submit all the information entered in the task assignment editor (
HTTP/HTTPS POST PostProjSchedule.htm allows the client processor 602 to submit all the information entered in the project schedule editor (
HTTP/HTTPS POST PostMembSchedule.htm allows the client processor 602 to submit all the information entered in the project member's schedule editor (
The web pages for the various editors (TaskAssignEditor.htm, ProjScheduleEditor.htm, and MembScheduleEditor.htm) include files that contain Javascript or PHP script, according to one non-limiting embodiment. The scripting languages used to perform the various functions described herein may vary from implementation to implementation. When a web browser (e.g., client processor 602) requests the web page of an editor, the editor web page and all the files corresponding to Javascript are passed to the web browser, whereby the web browser processes the Javascript. However, the files for the PHP script are not passed to the web browser. The PHP script are processed in the web server, such as web servers 507, 530 of
The behavior of the system in response to a selection of the “Consolidate” button is the same as for a selection of the “Finish” button. Both buttons cause (a) the addition and updating of the appropriate database with information from the project schedule editor, (b) the aggregation of the members' individual schedules with the project schedule, (c) the addition and updating of the project schedule in the database, and (d) the creation of the project schedule web page. Further, “Consolidate” redisplays the project schedule editor with the updated project schedule by requesting ProjScheduleEditor.htm again.
The TaskAssignment table 1202 stores the project tasks and corresponding subtasks of a project. The TopLevelProjectTask table 1204 stores the schedule of the project tasks that are in the TaskAssignment table 1202. The Level1MemberTask table 1206 stores the schedule of the member tasks which are assigned in the TaskAssignment table 1202 and links to the schedule of its corresponding project task in the TopLevelProjectTask table 1204. These links between the tables enable the automatic aggregation of the member schedules with the project schedule. The Level1MemberTask table 1206 also stores the schedule of the member tasks that are not related to any project task. The LevelXMemberTask tables (where X is 1, 2, 3, and 4) and the MemberTasks table 1208 store and manage links between the various levels of tasks of a member. The lower level tasks are more detailed tasks of the upper level tasks. The organization of these tables maintains the schedule of a member. The ProjectTeam table 1210 contains information about the project members. The project member information for a project member includes (a) a role, to determine access privileges to the various editors, (b) a directory for determining the location at which the member schedule web page is stored, and (c) IDs used for determining the identifier of the member tasks at various levels.
The log in process uses information in the ProjectTeam table 1210 to determine access privileges to a requested editor before displaying the editor. The task assignment editor uses and/or updates information in the tables DefaultTasks 1212, TaskAssignment 1202, TaskAssignmentHistory 1218, TopLevelProjectTask 1204, and MemberTasks 1208. The project schedule editor uses and/or updates information in the tables DefaultTasks 1212, TaskAssignment 1202, TopLevelProjectTask 1204, MemberTasks 1208, and Level1MemberTask 1206. The member schedule editor uses and/or updates information in the tables ProjectTeam 1210, TaskAssignment 1202, TopLevelProjectTask 1204, MemberTasks 1208, and LevelXMemberTask.
Descriptions of the various tables depicted in
DefaultTasks table 1212—this table contains the names of tasks that are typically tasks for all projects. In the context of software development projects, some examples of default tasks are Project Plans, Requirements, and Top Level Design.
ProjectTeam table 1210—this table contains information about project members for a project. sMemberLabel is a 2 to 4 character string used to identify a project member when displaying the project schedule, which shows the project tasks and associated member tasks as depicted in
nMemberTaskID is a number assigned to a project member that is used to determine the ID of a task for that member. According to one embodiment, the nMemberTaskIDs are used as the start ID for a task. Depending upon the size of the project team, the ID can be MOD 10 (1, 2, . . . , 9) for a small team or MOD 100 (1, 2, . . . , 99) or higher for a large team. The task IDs are increments of the MOD. For example, if the nMemberTaskID of project member ‘test1’ is 1, then the task IDs of test1's task will be 11, 21, 31, and so forth (or 101, 201, 301, and so forth for a large team). The task ID uniquely identifies a task for a project member even if the name of some of the tasks are the same. The task ID also uniquely identifies a task at all levels. nLevelXMaxTaskID is a number used to maintain the highest task IDs that have been used so far for the different level tasks of a project member. These numbers provide the starting IDs used to determine the task IDs of tasks that are added in the member's schedule editor session. These values are retrieved and updated after each editor session. Except for the values for nLevelXMaxTaskID, the values for the other entries must be set prior to the beginning of a project.
TaskAssignment table 1202—this table contains information about the project tasks and its subtasks that are assigned to project members for a project. sTaskName is used for the names of the tasks and nProjectTaskID are the IDs associated with the tasks. The project start task ID is 0 so that the ID for its tasks will be increments of the MOD (10, 20, 30, . . . for small team). sLevel1TaskName is used for the names of the subtasks (member tasks) associated with the project tasks and nLevel1TaskID is used for the IDs associated with the subtasks. sMemberLabel is used to identify the project members that are assigned the subtasks. bIsObsoleted is used to indicate whether the task has been removed from the project. Even though a task is deleted from the schedule, information about the task is maintained in the database. Values for sTaskName, nProjectTaskID, sLevel1TaskName, and sMemberLabel can be added to the TaskAssignment table 1202 through a task assignment editor session. The project schedule editor session can add values for sTaskName and nProjectTaskID. Only the member schedule editor session can add values for nLevel1TaskID.
TopLevelProjectTask table 1204—this table contains information about the scheduling of project tasks. sTaskName is used for the names of the tasks and nProjectTaskID is used for the IDs associated with the tasks. planStart and planEnd are used for the expected dates for starting and completing the task. actualStart and actualEnd are used for the actual dates in which the task was started and completed. setDate is used for the date in which the planned dates were set or modified. nScheduleRevNumber is used for the revision number of the task schedule. The latest schedule for a project task corresponds to the highest revision number. All revisions of a project task are maintained in the TopLevelProjectTask table 1204 to track the changes in the project task's schedule. The revision is incremented only when the planned dates are changed in the project schedule editor on different days. All values for nProjectTaskID, sTaskName, dates, and nScheduleRevNumber are added or updated in the TopLevelProjectTask table 1204 through a project schedule editor session or a task assignment editor session.
MemberTasks table 1208—this table contains information about all the tasks (tasks at all levels) for all the project members. Associated with each member (sMemberName) of a project are the task Ids and nLevelXTaskID, which identify all the tasks and their relationship with one another. As with the TaskAssignment table, bIsObsoleted indicates if the task has been removed from the project member's schedule. bIsCompleted indicates if the tasks is completed. nLevelXTaskID is used for the tasks which are added to the MemberTasks table 1208 and are determined from the nLevelXMaxTaskID of the ProjectTeam table 1210 when new tasks are added in the member's schedule editor session. Values in the table can be updated or modified (blsObsoleted or bIsCompleted) from the results of any of the three editor sessions (member schedule, project schedule, task assignment). The MemberTasks table 1208 is important to provide a link between the lower level task schedules with the upper level task schedules.
LevelXMemberTask table (e.g., Level1MemberTask table 1206, Level2MemberTask table 1214, Level3MemberTask table 1216)—this table contains information about the scheduling of member tasks. sLevelXTaskName is used for the name of the tasks and nLevelXTaskID is used for the IDs associated with the tasks. nLevelXTaskID for the tasks which are added to the table are determined from the nLevelXMaxTaskID of the ProjectTeam table 1210 when new tasks are added in the member's schedule editor session. planStart and planEnd are used for the expected dates for starting and completing the task. actualStart and actualEnd are used for the actual dates in which the task was started and completed. setDate is used for the date in which the planned dates were set or modified. nScheduleRevNumber is used for the revision number of the task schedule. The latest schedule for a member task corresponds to the highest revision number. All revisions of a member task are maintained in the table to track the changes in the member task's schedule. According to one embodiment, the revision is incremented only when the planned dates are changed in the member schedule editor. Each LevelXMemberTask table contains a task ID for upper level tasks (except for level 1, where a task either has a project task as its parent or no parent task). This provides for a task a link to its parent task and its child tasks. All values for parent task ID, sLevelXTaskName, nLevelXTaskID, dates, and nScheduleRevNumber are added or updated in the table through the member schedule editor session. Only Level1MemberTask table 1206 contains the sMemberLabel to provide a link to the TaskAssignment table 1202.
The database shows only lower levels down to level 4. However, the database can be modified to include lower levels for greater details in the task schedule.
TaskAssignmentHistory table 1218—this table contains information about the history of the assignment to project members of tasks associated with project tasks. This table maintains information about the project members that were previously assigned the tasks before the tasks were reassigned to other project members. nProjectTaskID are the IDs associated with the tasks. sLevel1TaskName are the names of the subtasks (member tasks) associated with the project. sMemberLabel are the project members that are assigned the subtasks. nRevNumber is the revision numbers of the assignment of tasks to project members. The nRevNumber shows the reassignment of the tasks in the project. The task assignment editor 102 (
The LoginProcessor 1302 package provides the web page to display the form that allows a project member to log in to one of the editors. When the member submits the form, the LoginProcessor 1302 package processes the information entered by the member to validate the information. If the information is valid and if the member has the appropriate access privilege, the LoginProcessor 1302 package redirects the system to one of the packages corresponding to the editors.
The TaskAssignmentProcessor 1304 package provides the web page to display the task assignment editor 102 (
The ProjectScheduleProcessor 1306 package provides the web page to display the project schedule editor 202 (
The MemberScheduleProcessor 1308 package provides the web page to display the member schedule editor 302 (
Except for the redirection of the LoginProcessor 1302 package to the editor packages, the processor packages are independent of each other and, generally, there is no interaction between the editor packages. Each of the processor packages 1302-1308 interacts with a database 1310 (e.g., databases 506, 536 of
According to an embodiment, each of the editor processor 1304-1308 packages comprises PHP script files, JavaScript files, and HTML files. The PHP script files obtain project and task information from the database 1310 and generate the JavaScript that displays the editor on the client processor 602 (
The Web Page for XXX 1406 (where “XXX” refers to either TaskAssignment, ProjectSchedule, or MemberSchedule) integrates the following packages to display the editor. The web page 1406 includes all the PHP script files of a XXXPHPProcessor 1408 package and all the javascript files of a XXXJavaScriptProcessor 1410 package to display and manage the editor. All the PHP script files are processed on the web server (e.g., web server 507, 530 of
The Web Page for PostXXX 1412 integrates the following packages that post the information and generate the post web page. The Web Page for PostXXX 1412 includes all the PHP script files of PostXXXPHPProcessor 1414 package to post the information from the editor and all the PHP script files of XXXWebPageGenerator 1416 package to create the web page. The PostXXXPHPProcessor 1414 package obtains all the task information from the editor and adds or updates the task information in the database. The XXXWebPageGenerator 1416 package obtains task information from the database to generate the appropriate web page.
Each of the packages of
The CMemberScheduleManager 1502 class provides an interface for the MemberSchedulePHPProcessor package 1500 and manages the classes in the MemberSchedulePHPProcessor package 1500 to generate the Javascript. The CMemberScheduleInitialData 1504 class generates the Javascript for setting the initial data in the editor. The initial data is the member tasks that are assigned to the project member, which the member can add to their schedule. The CMemberScheduleTaskRowData 1506 class generates the Javascript for displaying rows of member tasks that have been added to the member's schedule in previous editor sessions. The CJavaScriptlnterface 1508 class generates the sequence of Javascript that creates the initial editor in the web browser and will interface with the MemberScheduleJavaScriptProcessor 1600 package of
The CEditorManager 1602 class provides the interface for this package and creates the web page and form for the member schedule editor 302. The CTableManager 1604 class creates the table for the member schedule editor 302 and manages all events that affect the table. The CMemberScheduleTable 1606 class initializes and manages the table for the member schedule editor 302 and creates and manages the rows of the table. The CMemberScheduleRow 1608 class initializes and manages a row of the table for the member schedule editor 302, manages all events that affect the row, and creates and manages the cells in the row. The CTaskCell 1610 class initializes and manages the task cell of a row and maintains information about a task. The CDateCell 1612 class initializes and manages the date cell of a row and maintains information about the schedule of a task. The structure SMemberTaskInfo 1614 allows member task information to be passed from the MemberSchedulePHPProcessor 1500 package to the MemberScheduleJavaScriptProcessor 1600 package to display the tasks in the editor. The CDetailTaskInfo 1616 class stores and maintains information about the detailed tasks of a task and is used to update the schedule of a task with its subtasks. CDateCell 1612 contains CDateSelector 1618 to display month, day, and year menu selections in the date cells. According to one embodiment, all the foregoing classes and structures of the MemberScheduleJavaScriptProcessor 1600 package are implemented in Javascript.
Table 1 illustrates a document object model representation of the member schedule editor 302 (
Each element constituent to an editor can be accessed through its id and the properties of the elements can be set to change the value and/or the display of the element. According to an embodiment, for each of the elements in the member schedule editor 302, the element is wrapped within one of the classes of the MemberScheduleJavaScriptProcessor 1600 package of
Table 2 below illustrates the attribute members of the CTaskCell 1610 class of the MemberScheduleJavaScriptProcessor 1600 package shown in
The CProjectScheduleManager 1902 class provides an interface for the ProjectSchedulePHPProcessor package 1900 and manages the classes in the ProjectSchedulePHPProcessor package 1900 to generate the Javascript. The CProjectScheduleInitialData 1904 class generates the Javascript for setting the initial data in the editor. The initial data is the project tasks that can be added to the project schedule. The CProjectScheduleTaskRowData 1906 class generates the Javascript for displaying rows of project tasks along with corresponding member tasks that have been added to the member's schedule in previous editor sessions. The CJavaScriptlnterface 1912 class generates the sequence of Javascript that creates the initial editor in the web browser and interfaces with the ProjectScheduleJavaScriptProcessor 2000 package. The CProjectEditorDBInterface 1908 class accesses information from the database that will be displayed in the editor. The CProjectEditorDBQueryGenerator 1910 class creates the SQL database queries for CProjectEditorDBInteface 1908. CProjectEditorDBInterface 1908 interfaces with CScheduleDB 1914 to access the database. CProjectScheduleInitialData 1904 and CProjectScheduleTaskRowData 1906 obtain task information from the database through CProjectEditorDBInterface 1908. According to an embodiment, the foregoing classes for ProjectSchedulePHPProcessor 1900 package are implemented in PHP script.
Table 3 illustrates the document object model representation of the project schedule editor 202 (
Table 4 illustrates the attribute members of the class CTaskCell 2008 of the ProjectScheduleJavaScriptProcessor 2000 package shown in
The CTaskAssignmentManager 2302 class provides an interface for the TaskAssignmentPHPProcessor 2300 package and manages all classes in the package to generate the Javascript. The CTaskAssignmentInitialData 2304 class generates the Javascript for setting the initial data in the task assignment editor 102 (
Table 5 illustrates the document object model representation of the task assignment editor 102 (
Table 6 below illustrates the attribute members of the class CTaskCell 2408 of the TaskAssignmentJavaScriptProcessor package shown in
As can be appreciated from
Table 7 illustrates the indexing of the software design specification of the object-oriented scheduling system described herein, to see the similarity in design. Table 7 lists the packages and classes within the packages, and shows the similarity of the design of the three editors.
Database Query Generation from Constant Strings with Placeholder Strings
Using constant query strings having placeholder strings provides an improvement from building the string through a series of string concatenations, which is difficult to read and comprehend. Each of the class diagrams for packages which access the database contain package constants that are used within the package, as shown in
The CXXXDBInterface class (e.g., CPostDBInterface 1706 class from
When the web page is requested by the client processor 602 (
A Method for Managing a Project Schedule with a Client-Server Based Project Schedule System
At block 3202, in response to a request to view an editor associated with a client-server based project schedule system, a server accesses first schedule-related information from a database. For example, a user at client processor 602 (
At block 3204, the server generates client-executable code for execution by the requesting client. This client-executable code generated by the server is for displaying the requested editor at the client, displaying the retrieved information in the appropriate fields of the editor, and for managing the editor at the client. For example, server processor 604 (
Appendices A, C, and E present example code listings for the respective editors, where the example code listings show the JavaScript denoted by the <script> tag and the PHP script enclosed within <?php and ?> tag. The editor pages are stored in the server processor 604, such as web servers 507, 530 (
At block 3208, the client executes the client-executable code, or at least some of such code, in order to display the first schedule-related information in the requested editor and to manage the data and editor, generally. Thus, initial display of the requested editor is now complete, based on the foregoing actions associated with each of the client and server processors.
Once the editor page is loaded at the client by executing the client-executable code (e.g., JavaScript) generated by the server, the user can begin to edit and/or add information associated with the editor. Thus, at block 3210, the client receives second schedule-related information from a user via the editor. For example, depending on the particular editor, the client processor 602 (
At block 3212, the client executes at least some of the client-executable code to manage and/or maintain the second schedule-related information in the editor at the client side. For example, execution of the code creates data structures and associations for managing the new or updated data at the client prior to submission of such data to the server, and provides the functionalities embodied in the editor page objects (e.g., HTML buttons, text entry objects, etc.).
At block 3214, the client passes the second schedule-related information from the editor to the server. Thus, at block 3216, the server stores the second schedule-related information in the database, from which it can be subsequently accessed for passing back to clients in response to requests. For example, schedule-related information may be passed from the server to a client in response to a request for a respective editor page (e.g.,
At block 3302, in response to a request associated with a particular editor of a network-based project schedule system, a particular query string associated with the particular editor is located. The query string, also referred to herein as a “constant query string” (e.g.,
At block 3304, a database query is generated by automatically replacing the one or more placeholder strings in the particular query string with corresponding values. For example, the placeholder string ‘%% ProjectNumber %%’ is replaced with value “J17”; the placeholder string ‘%% MemberLabel %%’ is replaced with the value “T1”; and the placeholder string ‘%% ProjectTasklD %%’ is replaced with the value “40”.
As discussed in reference to
As discussed in reference to
At block 3306, the automatically generated database query is submitted to the database and, at block 3308, results of the database query are returned in response to the request.
At block 3402, in response to an event that affects a row of a display table of an editor, a class object corresponding to the affected row directly accesses one or more attributes, of the class object, which correspond to elements of an editor associated with a project schedule system. Each row of the display table corresponds to a schedule task associated with a project schedule and displays values corresponding to elements of the editor. Significantly, the class object can directly access the attributes because the elements of the editor are configured as attributes of the class object. Thus, the class object does not have to construct the element id for the affected elements of the affected row and does not have to obtain such elements.
For example, a user edits schedule data for a particular task via the member schedule editor 302 (
At block 3404, the class object corresponding to the affected row directly manipulates a value for each of the one or more attributes of the class object based on the event. Continuing with the example, a member function of an object of the CMemberScheduleTaskRowData 1506 class of the XXXJavaScriptProcessor 1410 for the member schedule editor 302 sets the values of attributes of the object and thereby manipulates the values of elements of the member schedule editor 302.
At block 3406, a client transmits to a server the value for each of the one or more attributes, including the values for the attributes that were manipulated at block 3404. For example, the client processor 602 (
“Design Pattern” refers to a general design that addresses a recurring design problem in object-oriented systems. The general design of the member schedule editor is applied to the task assignment editor and project schedule editor. Design Pattern is described in “Design Patterns: Elements of Reusable Object-Oriented Software” by Erich Gamma, et al., published by Addison-Wesley, the content of which is incorporated by reference in its entirety for all purposes as if fully set forth herein.
Classes CTaskAssignmentTaskRowData 3602, CProjectScheduleTaskRowData 3612, and CMemberScheduleTaskRowData 3622 are parts of their respective XXXPHPProcessor packages that obtain task information from the database and generate the client code to display the task information in a row in its corresponding editor. CTaskAssignmentTaskRowData 3602 obtains information about the project tasks and corresponding member tasks and the assignment of the member task to a member. CTaskAssignmentTaskRowData 3602 generates the client code to display the project task rows and the member task rows with member assignment in the task assignment editor. CProjectScheduleTaskRowData 3612 obtains information about the project tasks and corresponding member tasks and the schedule of the tasks. CProjectScheduleTaskRowData 3612 generates the client code to display the row for the project task schedules along with corresponding member task schedules in the project schedule editor. CMemberScheduleTaskRowData 3622 obtains information about the member tasks and all detailed tasks (down to level 4 tasks) and the schedule of the tasks. CMemberScheduleTaskRowData 3622 generates the client code to display the rows for the member task schedules along with corresponding detailed task schedules in the member schedule editor. The package XXXPHPProcessor for each editor uses a class to generate code to display the task row in the editor in the client processor even though the information is different.
Classes CTaskAssignmentTable 3604, CProjectTableManager 3614, and the combination of CTableManager and CMemberScheduleTable 3624 are parts of their respective XXXJavaScriptProcessor packages that create, manage, and maintain the table and rows of a corresponding editor. Since the member schedule editor is relatively more complex (i.e., adding and deleting tasks at different levels, setting actual dates, updating lower level task schedules with higher level task schedules) than the task assignment editor and project schedule editor, two classes are used to manage the table and rows. The components of the table and the type of events that can occur in the table of the editors differ, but can all be represented by one or two classes in the design of the package. The XXXJavaScriptProcessor packages contain classes corresponding to the different parts of the editors such as table, rows, and cells.
Classes CTaskAssignmentUpdater 3606, CProjectTaskUpdater 3616, and CMemberTaskUpdater 3626 are parts of their respective PostXXXPHPProcessor packages that update the task information in the database with the information passed from the corresponding editor sessions on the client processor. Depending upon the action performed on a task in the editor, the appropriate action is taken to update the information about the task in the database. The type of action varies among the different editors and the details of the action are handled within the design of the class, whereas the overall function of the class is to update the task information in the database. Therefore, the design pattern can be used for posting the information from the editor session to the database for all the editors.
Classes CTaskAssignmentWebPageManager 3608, CProjectScheduleWebPageManager 3618, and CMemberScheduleWebPageManager 3628 are parts of their respective XXXWebPageGenerator packages that manage the classes that generate the web page for the task assignment, project schedule, and member schedule, respectively. CTaskAssignmentWebPageManager 3608 uses various classes to create the web page with a table showing the project tasks and member tasks, where the member tasks show the member assigned to the tasks and the tasks' history.
CProjectScheduleWebPageManager 3618 uses the various classes to create the web page with a table showing the project task schedule and its member task schedules along with the history of the schedules. CMemberScheduleWebPageManager 3628 uses the various classes to create the web page with tables showing the task schedule with its detailed task along with the history of the schedule. The same design pattern is used by all the editors that generate web pages containing different information.
Classes CTaskAssignmentWebPageGeneratorDBInterface 3610, the combination of CProjectWebPageDBInterface and CProjectWebPageDBQueryGenerator 3620, and the combination of CWebPageDBInterface and CWebPageDBQueryGenerator 3630 are part of respective XXXWebPageGenerator packages that handle the interface with the database, to access task information needed for generating the web pages for the task assignment, project schedule, and member schedule, respectively. Each class or combination of classes for the editors represents a database interface that generates the database queries and obtains information in response to the queries.
In the description of the classes of the packages of
Appendix A shows an example code listing of a web page for the project schedule editor. The example code listing shows the JavaScript denoted by the <script> tag and the PHP script enclosed within <?php and ?> tag. The web page is stored in the server processor 604 (
Appendix B shows example JavaScript code generated by the PHP script of Appendix A. The JavaScript code replaces the PHP code in the web page. The JavaScript code includes task scheduling information obtained from the database. The task information is assigned to a data structure to pass the information to JavaScript for processing (for example, var glo_ProjectTaskInfo=new SProjectTaskInfo( ) and glo_ProjectTaskInfo.xxx=“value”). Also, JavaScript code is generated to create an object and to call the member function of the object to provide the initial display of the project schedule editor (for example, var glo_EditorManager=new CProjectEditorManager( ), glo_EditorManager.setup_createEditor(“J99”), and glo_EditorManager. setup_addTaskToEditor(glo_ProjectTaskInfo).
The task assignment editor (Appendices C and D) and member schedule editor (Appendices E and F) follows a similar format for its web page to generate the editor, as shown in Appendices A and B for the project schedule editor.
Appendix C shows an example code listing of a web page for the task assignment editor. The example code listing shows the JavaScript denoted by the <script> tag and the PHP script enclosed within <?php and ?> tag. The web page is stored in the server processor 604 (
Appendix D shows example JavaScript code generated by the PHP script of Appendix C. The JavaScript code replaces the PHP code in the web page. The JavaScript code includes task scheduling information obtained from the database. The task information is passed to JavaScript for processing. Also, JavaScript code is generated to create an object and to call the member function of the object to provide the initial display of the task assignment editor (for example, var glo_EditorManager=new CTaskAssignmentEditorManager( ), glo_EditorManager.setup_createEditor(“J99”), and glo_EditorManager. setup_addTopLevelTaskToEditor(“10”, “Project Preparation”).
Appendix E shows an example code listing of a web page for the member schedule editor. The example code listing shows the JavaScript denoted by the <script> tag and the PHP script enclosed within <?php and ?> tag. The web page is stored in the server processor 604 (
Appendix F shows example JavaScript code generated by the PHP script of Appendix E. The JavaScript code replaces the PHP code in the web page. The JavaScript code includes task scheduling information obtained from the database. The task information is assigned to a data structure to pass the information to JavaScript for processing (for example, var glo_MemberTaskInfo=SMemberTaskInfo( ) and glo_MemberTaskInfo.xxx=“value”). Also, JavaScript code is generated to create an object and to call the member function of the object to provide the initial display of the member schedule editor (for example, var glo_EditorManager new CEditorManager( ), glo_EditorManager.setup_createEditor(“J99”, “test1”), and glo_EditorManager. setup_addTaskToEditor(glo_MemberTaskInfo).
Graceful Termination of Interpretable Script Code Executing in a Client Browser Window
The scripted code may be programmed in JavaScript or other script languages such as JScript and ECMAScript. Originally defined by Netscape, JavaScript is an interpreted language which is processed “on-the-fly” by the web browser add-in components. Various open source versions of JavaScript are widely available. Embodiments are not limited to JavaScript as defined by Netscape or as that term is ordinarily used. Thus, as used herein, the term JavaScript refers broadly to any script-based programming language and not just JavaScript from Netscape, including JScript, ECMAScript, etc.
In an embodiment, a web browser enabled client requests web pages for a project task editor from a web server. The web server returns an HTML web page containing embedded JavaScript included with the web page or generated by the web server which will display a task editor containing task information when the JavaScript is executed by the client. The web page also contains JavaScript code for classes, global functions, and constants that are used by the web enabled client to create, manage, and maintain the task editor. The JavaScript code may be included with the web page or generated in the web page by the web server. When the web enabled client receives the web page for the editor, the client processor executes the JavaScript code generated by the web server for the initial display of the task editor.
The JavaScript code will create objects corresponding to the classes included with the web page and call the member functions of the classes along with calling the global functions to display and manage the task editor. The JavaScript code is enclosed within a Try block of the JavaScript Try and Catch Block statement to handle abnormal conditions during the execution of the JavaScript code.
The use of Try and Catch Block statements along with throwing an exception in the JavaScript code to handle the abnormal condition allows for the graceful termination of JavaScript code executing on the web browser enabled client. Other possible solutions to handle abnormal conditions during the creation, management, and execution of the task editor on the web browser enabled client include having a global function redirect to a new web page that displays a message about the editor session. The global functions may also be useful for debugging purposes to display a message indicating the location of the abnormal condition which may include the filename, the line number, the class, and/or the name of the function that called the global function. Thus, the JavaScript may be modified to identify for diagnostic purpose, the location where the global function is called.
Generally, web servers 507, 530 comprise resources for the display and management of the editors. The web servers 507, 530 interact with databases 506, 536, respectively, to store, maintain, and manage task assignment and task schedule information, e.g., data 508, 538. For purposes of illustrating a clear example, two web servers and two databases are shown in
Workstations 501, 502 may be computer systems configured with one or more web browsers, and are utilized, for example, by the engineers/developers to complete tasks associated with a product development project. The project may involve any kinds of tasks. Examples of such tasks include initiating projects, preparing and maintaining task schedules, designing software architecture, creating specifications, creating software code, implementing and testing software code, inspecting various task products, etc. In addition, project managers utilize workstations 501, 502 for accessing information to review and manage the progress of the project. The developers and managers transmit communications through the network 500 to the other connected components, e.g., web servers 507, 530; databases 506, 536; and handheld device 520 and laptop 522, via access point(s) 524.
The workstations 501, 502, handheld devices 520, and laptop 522, which can access the web pages from the web servers 507, 530, can process JavaScript embedded in the web pages to manage task editors and other applications included in the browsers. The browsers process JavaScript using browser add-in components. Examples of browser add-in components include ActiveX Controls, browser extensions and browser helper objects. In most browser configurations, a JavaScript add-in component is provided which allows the web browsers installed in each of the workstations 501, 502 to process JavaScript received from the web servers 507, 530.
The web servers 507, 530 are configured with a combination of computer hardware and software using protocols such as Hypertext Transfer Protocol [HTTP] and Transmission Control Protocol/Internet Protocol [TCP/IP]. The web servers 507, 530 serve the files that form web pages (e.g., Hypertext Markup Language [HTML] or Extensible Markup Language [XML] files), to users, such as developers or managers at a workstation 501, 502. For example, an Apache web server, which contains modules for the execution of PHP, VBasicScript or Ruby scripts, may be used as the web server application for the web server 507, 530. Non-scripting object oriented languages such as C, C++, C#, Java, CORBA, PERL, AWK, or Visual Basic may be used.
In an embodiment, the information that is exchanged and managed is served by the web servers 507, 530 over the network 500. The databases 506, 136 may be programmed in any convenient relational database language, by way of example and not limitation, ORACLE, Sequel Server, MySQL, SQL, MS ACCESS, DB2, MS FOXBASE, DBASE, PostgreSQL and RBASE.
Additional aspects of the programmatic techniques described herein may be implemented and executed on the web servers 507, 530, although these techniques are not limited to such an implementation. The techniques could also be implemented on any other processing system, such as workstations 501, 502 or a computer system as illustrated in
Databases 506, 536 depict typical databases for storing data 508, 538 related to the development project, thus providing access to the information by authorized individuals at workstations 501, 502, through queries transmitted over the network 500. Any type of data may be stored on databases 506, 536. Examples include project initiation forms, member and project task schedules, specifications, software code, inspection reports, web page files, and document directories and indexes.
The network 500 may comprise a packet-switched network for facilitating the exchange of information between and among various connected components, such as workstations 501, 502, web servers 507, 530, and databases 506, 536. The network 500 may be a Local Area Network (LAN), such as an Ethernet, Fast Ethernet, token ring, or wireless LAN such as specified in IEEE standards 802.11a and 802.11b. Network 500 may also be a Wide Area Network (WAN) over one or more internetworks, for facilitating communication with remote users through a Virtual Private Network (VPN), or the network 500 may represent a combination of a LAN and a WAN. In addition, network 500 can be formed using a variety of different mediums, including but not limited electrical, wire or cable, optical, or wireless connections.
In an embodiment, the web server 507 generates one or more login forms at operation 3715 containing JavaScript code which are then sent at operation 3720 to the web browser of the requesting client 501. The JavaScript code may be included with the web page containing the forms or generated by the web server. The user completes the login forms at operation 3725 which are then submitted at operation 3730 to the web server 507 for access approval. If access to the project management system is allowed, the web server 507 generates and sends one or more forms associated with a task editor at operation 3740 to the requesting web enabled client 501.
The web server will pass the HTML web page that includes JavaScript code along with web server generated JavaScript code that will be executed on the client-side web browser to display a task editor. The web server will update a project management system 508, 536 database(s) with information entered in the task editor when it is submitted by the client-side web browser and will create a web page for task information. The programming language executed by the web servers 507, 530 can be PHP script but any language can be used that can be executed by the web server such as Perl or Ruby. Execution of the web server code occurs generally in two main web pages; one for generating and displaying the task editor on the client-side web browser and the other for submitting the task editor session information received from the client-side web browser.
At any point hereinafter, if an abnormal condition at operation 3760 is determined in the code executing on the web server 507, then a global function is called which generates a termination JavaScript at operation 3770 which is sent to the client web browser 501 and the executing server code is terminated at operation 3765.
In an embodiment, a window of the web browser associated with the web server encountering the abnormal condition is cleared, and information is displayed in the window which includes information useful in debugging the fault which caused the abnormal condition. For example, a filename, line number, class, and/or name of a function that called the global function.
If an abnormal condition is not found, the web page for the task editor forms containing JavaScript code generated by the web browser are sent to the client of the web browser at operation 3740 establishing the task editor session. Analogously, if at any point hereinafter, the web browser of the client 501 evaluates the received JavaScript from the web server 507 for abnormal conditions as is described in co-pending US patent application No. N, Attorney Docket No. 49986-0642, filed D and entitled “Graceful Termination of a Web Enabled Client.”
An abnormal condition at operation 3775 causes the web browser of the client to terminate the current task editor session at operation 3780 with the web server 507, clears the currently displayed web page in the client-side browser window and displays a web page in the client-side browser window which informs the user that the task editor session has terminated due to an abnormal condition.
If the script for the task editor executes without an abnormal condition, the user enters task editor information into the received forms at operation 3745 and submits the form(s) at operation 3750 to the web server 507. The web server 507 again verifies the received information from the web enabled client and executing server code to ensure that an abnormal condition has not occurred. If no abnormal conditions have occurred on either web server 507 or client 501, processing ends normally.
An example global function written in PHP to generate JavaScript code to be executed by the client-side browser and terminate execution of the PHP code on the web server is provided in TABLE 1.
The code writes out JavaScript code that clears the browser window and displays a message in the browser before stopping the execution of PHP.
An example PHP code to determine if an abnormal condition has occurred in various PHP code modules is provided in TABLE 2.
Processing by the web server begins at step 3800 when a request is received from a web enabled client. At step 3805, server code is executed by the web server. During the execution of the code for the web server, tests at step 3810 for abnormal conditions are performed in various locations within the code. Examples of abnormal conditions include but are not limited input values to a function which do not correspond to expected values, attribute members of an object which must exist, or objects which must be created.
Abnormal conditions encountered will prevent the code on the web server from executing properly. If an abnormal condition is determined at step 3810 then a global function is called which generates a JavaScript which is passed to the client-side browser to execute at step 3820.
Embodiments may include a debug mode and a production mode and may execute different behavior depending on the current mode. In an embodiment, at step 3822 a test is performed to determine whether the server is in debug mode. If not, then JavaScript code is created and sent at step 3824 to clear the display window and display a generic error message, such as “Editor Session Failed.” Thus when the JavaScript that is passed to the client side browser is executed, the currently displayed window in the client-side browser will be cleared and the window will display an error message which informs the user that the task editor session has abnormally terminated. If the server is in debug mode, then in step 3825 the JavaScript causes displaying a message providing more detailed information about the abnormal condition for possible use in debugging.
After the client-side JavaScript is generated by the web server, execution of the server side code is terminated at step 3830, and the abnormal termination process on the web server ends at step 3835.
Alternately, if an abnormal condition has not occurred at step 3810, execution of the web server code continues until all the code on the web server has completed execution at step 3815, ending normal termination process on the web server at step 3835.
In an embodiment, the global function is programmed to capture and display for debugging purposes, at step 3825, a message indicating the location of the abnormal condition which may include the filename, code line number, class, and/or name of the function that called the abnormal termination global function.
Computer system 3500 may be coupled via bus 3502 to a display 3512, such as a cathode ray tube (CRT) or a liquid crystal display (LCD), for displaying information to a computer user. An input device 3514, including alphanumeric and other keys, is coupled to bus 3502 for communicating information and command selections to processor 3504. Another type of user input device is cursor control 3516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 3504 and for controlling cursor movement on display 3512. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
Embodiments of the invention are related to the use of computer system 3500 for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system 3500 in response to processor 3504 executing one or more sequences of one or more instructions contained in main memory 3506. Such instructions may be read into main memory 3506 from another computer-readable medium, such as storage device 3510. Execution of the sequences of instructions contained in main memory 3506 causes processor 3504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 3504 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Examples of non-volatile media include, without limitation, optical, magnetic disks, or magneto-optical disks, such as storage device 3510. Volatile media includes dynamic memory, such as main memory 3506. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 3502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Common forms of computer-readable media include, without limitation, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium; a CD-ROM, DVD, any other optical or magneto-optical medium; punchcards, papertape, any other physical medium with patterns of holes; a RAM, a PROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 3504 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 3500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 3502. Bus 3502 carries the data to main memory 3506, from which processor 3504 retrieves and executes the instructions. The instructions received by main memory 3506 may optionally be stored on storage device 3510 either before or after execution by processor 3504.
Computer system 3500 also includes a communication interface 3518 coupled to bus 3502. Communication interface 3518 provides a two-way data communication coupling to a network link 3520 that is connected to a local network 3522. For example, communication interface 3518 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 3518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 3518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 3520 typically provides data communication through one or more networks to other data devices. For example, network link 3520 may provide a connection through local network 3522 to a host computer 3524 or to data equipment operated by an Internet Service Provider (ISP) 3526. ISP 3526 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 3528. Local network 3522 and Internet 3528 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 3520 and through communication interface 3518, which carry the digital data to and from computer system 3500, are exemplary forms of carrier waves transporting the information.
Computer system 3500 can send messages and receive data, including program code, through the network(s), network link 3520 and communication interface 3518. In the Internet example, a server 3530 might transmit a requested code for an application program through Internet 3528, ISP 3526, local network 3522 and communication interface 3518.
The received code may be executed by processor 3504 as it is received, and/or stored in storage device 3510, or other non-volatile storage for later execution. In this manner, computer system 3500 may obtain application code in the form of a carrier wave.
Alternative embodiments are described throughout the foregoing description, and in locations that best facilitate understanding the context of the embodiments. Furthermore, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from any broader inventive concepts. Therefore, the specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
In addition, in this description certain process steps are set forth in a particular order, and alphabetic and alphanumeric labels may be used to identify certain steps. Unless specifically stated in the description, embodiments are not necessarily limited to any particular order of carrying out such steps. In particular, the labels are used merely for convenient identification of steps, and are not intended to specify or require a particular order of carrying out such steps.
Functional implementation of the various embodiments described herein may be implemented equivalently in hardware, software, firmware, and/or other available functional components or building blocks. No specific limitation is intended to a particular device or programmatic sequence. Other variations and embodiments are possible in light of above teachings.
This application is related to co-pending US patent application No. N, Attorney Docket No. 49986-0643, filed Feb. 22, 2008, and entitled “Graceful Termination of a Web Enabled Client,” and co-pending U.S. patent application Ser. No. 11/724,963, filed Mar. 15, 2007, and entitled “Project Task Management System For Managing Project Schedules Over A Network,” and co-pending U.S. patent application Ser. No. 11/724,723, filed Mar. 15, 2007 and entitled “Database Query Generation For Project Task Management System For Managing Project Schedules Over A Network”, and U.S. patent application Ser. No. 11/724,757, filed Mar. 15, 2007 and entitled “Class Object Wrappers For Document Object Model (DOM) Elements For Project Task Management System For Managing Project Schedules Over A Network”, and co-pending U.S. patent application Ser. No. 11/449,116, filed Jun. 7, 2006 and entitled “Use of Schedule Editors In a Network-Based Project Schedule Management System,” and co-pending U.S. patent application Ser. No. 11/449,130, filed Jun. 7, 2006 and entitled “Consolidation of Member Schedules With a Project Schedule In a Network-Based Project Schedule Management System”, and co-pending U.S. patent application Ser. No. 11/449,133, filed Jun. 7, 2006 and entitled “Use of a Database In a Network-Based Project Schedule Management System”, and co-pending U.S. patent application Ser. No. 09/881,250, filed Jun. 13, 2001, now U.S. Pat. No. 7,191,141 B2 and entitled “Automated Management Of Development Project Files Over A Network”, and co-pending U.S. patent application Ser. No. 10/059,694, filed Jan. 28, 2002, and entitled “Project Management Over A Network With Automated Task Schedule Update,” the entire contents of which are hereby incorporated by reference in their entirety for all purposes as if fully disclosed herein.