Browser based web site generation tool and run time engine6546397
Abstract
A method and apparatus for designing and building a web page. The apparatus includes a browser based build engine including build tools and a user interface. The build tools are operable to construct a single run time file and an associated database that describe, and when executed, produce the web page. The user interface includes a build frame and a panel. The build frame is operable to receive user input and present a WYSIWIG representation of the web page. The panel includes one or more menus for controlling the form of content to be placed on the web page.
Claims
I claim:
1. A method to allow users to produce Internet websites on and for computers having a browser and a virtual machine capable of generating displays, said method comprising:
(a) presenting a viewable menu having a user selectable panel of settings describing elements on a website, said panel of settings being presented through a browser on a computer adapted to accept one or more of said selectable settings in said panel as inputs therefrom, and where at least one of said user selectable settings in said panel corresponds to commands to said virtual machine;
(b) generating a display in accordance with one or more user selected settings substantially contemporaneously with the selection thereof;
(c) storing information representative of said one or more user selected settings in a database;
(d) generating a website at least in part by retrieving said information representative of said one or more user selected settings stored in said database; and
(e) building one or more web pages to generate said website from at least a portion of said database and at least one run time file, where said at least one run time file utilizes information stored in said database to generate virtual machine commands for the display of at least a portion of said one or more web pages.
2. An apparatus for producing Internet websites on and for computers having a browser and a virtual machine capable of generating displays, said apparatus comprising:
(a) an interface to present a viewable menu of a user selectable panel of settings to describe elements on a website, said panel of settings being presented through a browser on a computer adapted to accept one or more of said selectable settings in said panel as inputs therefrom, and where at least one of said user selectable settings in said panel corresponds to commands to said virtual machine;
(b) a browser to generate a display in accordance with one or more user selected settings substantially contemporaneously with the selection thereof;
(c) a database for storing information representative of said one or more user selected settings; and
(d) a build tool having at least one run time file for generating one or more web pages, said run time file operating to utilize information stored in said database to generate commands to said virtual machine for generating the display of at least a portion of said one or more web pages.
3. The apparatus of claim 2, wherein said database is a multi-dimensional array structured database.
4. The apparatus of claim 3, wherein said representative information is Boolean data, numeric data, string data or multi-dimensional arrays of various multimedia objects.
5. The apparatus of claim 4, wherein said elements include multimedia objects selected from the group consisting of a color, a font, an image, an audio clip, a video clip, a text area and a URL.
6. The apparatus of claim 2, wherein said elements are selected from the group consisting of a button, an image, a paragraph, a frame, a table, a form and a vector object.
7. The apparatus of claim 2, wherein said one or more web pages of a website is two or more web pages of a website, wherein said elements include web pages, and wherein said description of elements is a transition or an animation between two of said two or more web pages.
8. The apparatus of claim 2, wherein said elements include one or more objects on a web page, and wherein said description of elements are a transition or an animation of at least one of said elements on a web page.
9. The apparatus of claim 2, wherein said elements include a button or an images, wherein said selectable settings includes the selection of an element style, and wherein said build engine includes means for storing information representative of selected style in said database.
10. The apparatus of claim 9, wherein said elements are described by multiple object states.
11. The apparatus of claim 9, wherein said elements are described by a transformation or a timelines of said selected styles.
12. The apparatus of claim 9, wherein at least one of said elements is a child element, and wherein said element style is a child element style.
13. The apparatus of claim 12, wherein at least one of said element is described by timelines of said child elements.
14. The apparatus of claim 2, wherein said elements include buttons or images, wherein said description of elements is a transition or a timeline which is selected according to input from a mouse, and wherein said build engine includes means for storing information representative of said selected description of elements in said database.
15. The apparatus of claim 14, wherein at least one of said description of elements is a timeline or an animation.
16. The apparatus of claim 2, wherein said elements include one or more objects on two or more web page, wherein at least one of said description of elements is a transition or a timeline, and wherein said build engine includes means to synchronize said description of said one or more objects on one web page between said two or more web pages.
17. The apparatus of claim 2, wherein one or more of said elements is a button or an image, wherein said description of elements is a transition, an animation or a timeline, and wherein said build engine includes means to synchronize said description of said one or more elements.
18. The apparatus of claim 2, wherein at least one of said elements is an object elements selected from the group consisting of a button and an image, and web pages as elements of a website, wherein said description of said object elements is a transition, an animation or a timeline, wherein said description of said web pages is a transition or a timeline, and wherein said build engine includes means to synchronize said description of said object elements and said description of said web pages.
19. The apparatus of claim 2, wherein said elements include an object and a child object, wherein said description of said elements is a timeline or an animation, and wherein said build engine activates said description of said elements according to input from a mouse.
20. The apparatus of claim 2, wherein at least one of said elements is a child button or a child object, wherein said description of said elements is a timeline, a transition or an animation, and wherein said build engine includes means for defining said description of said element.
21. The apparatus of claim 17, wherein said elements further includes at least two child object elements, and said means to synchronize includes means for synchronizing said description of at least two of said at least two child object elements.
22. The apparatus of claim 18, wherein said elements further includes a child object element, and said means to synchronize includes means for synchronizing said description of said child elements.
23. The apparatus of claim 19, wherein said description of elements is a transition or a timeline which is selected according to input from a mouse, and wherein said build engine includes means for storing information representative of said selected description in said database.
24. The apparatus of claim 2, wherein said run time files include one compressed website specific, customized run time engine program file and one compressed website specific, customized run time engine library file.
25. The apparatus of claim 24, wherein said run time files include a dynamic web page scaling mechanism, whereby each of said one or more generated web pages is scaled for viewing on said display.
26. The apparatus of claim 2, wherein said run time files includes one compressed website specific, customized run time engine program file and one compressed website specific, customized run time engine library file, wherein said run time files include a dynamic web page scaling mechanism, and wherein the build engine generates an HTML shell file for each set of one or more run time files which instructs said browser to display a background in said browser window identical to that which the run time engine will draw, invokes said dynamic web page scaling mechanism, and invokes said run time engine.
27. The apparatus of claim 2, wherein said run time files include a multi-level program animation model that presents multiple user interactions and time sensitive operations simultaneously.
28. The apparatus of claim 2, wherein at least one of said elements includes individual ones of multiple audio tracks, and wherein said build engine includes means for associating at least one of said individual audio tracks with a web page or an object on a web page and means for synchronizing multiple audio tracks.
29. The apparatus of claim 2, further including file size reduction means for reducing the total size of said run time files to less than approximately 50K and for reducing the total size of said the run time file of the first web page of said website to less than 25K.
30. The apparatus of claim 29, wherein said total size of said run time files is from approximately 12K to approximately 50K.
31. The apparatus of claim 29, wherein said elements include a web page, an object, a paragraph, or combinations thereof, and wherein said file size reduction means includes means for tracking multiple high water marks for said elements to minimize the size of said at least a portion of said database generated by said build tool.
32. The apparatus of claim 29, wherein said file size reduction means includes means for identify website specific run time files.
33. The apparatus of claim 2, wherein said website has a first web page, wherein said run time files includes a main run time file and main database information corresponding to said first web page, and further includes a run time routine for simultaneously obtaining from the Internet and displaying said first web page and processing said database corresponding to others of said web pages.
34. The apparatus of claim 33, wherein at least one of said elements includes one or more images, and wherein the run time files includes an image observer operable to permit said one or more images of said website to be downloaded simultaneously with the execution of said run time files.
35. The apparatus of claim 2, wherein the build engine includes dynamic resizing means operable to redefine a size of a web page upon being display.
36. The apparatus of claim 35, wherein the dynamic resizing apparatus can be invoked in real time during the build process when a new web site file is opened, when the web page size of the existing web site is changed, or when the web page is zoomed to a different size.
37. An apparatus for producing Internet websites having one or more web pages on and for a computer having a browser and a virtual machine capable of generating a display, said apparatus comprising:
(a) an interface configured for building a website through control of website elements, said interface being operable through the browser on the computer to:
present a viewable menu of a user selectable panel of settings, accept a plurality of settings from said user selectable panel of settings to form an assembly of settings, and
generate the display in accordance with said assembly of settings contemporaneously with the acceptance thereof, at least one of said user selectable settings of said panel of settings being operable to generate said display through commands to said virtual machine;
(b) an internal database associated with said interface for storing information representative of one or more of said assembly of settings for controlling elements of the website; and
(c) a build tool to construct one or more web pages of said website having:
an external database containing data corresponding to said information stored in said internal database, and
one or more run time files,
where said run time files utilize information stored in said external database to generate virtual machine commands for the display of at least a portion of said one or more web pages.
38. The apparatus of claim 37, wherein said user selectable panel of settings arc selected from the group consisting of construction, manipulation, animation and transition of elements.
39. An apparatus to allow users to produce Internet websites on and for computers having a browser and a virtual machine capable of generating displays, said apparatus comprising:
(a) means for presenting a viewable menu of a user selectable panel of settings to describe elements on a website, said panel of settings being presented through a browser on a computer adapted to accept one or more of said selectable settings in said panel as inputs therefrom, and where at least one of said user selectable settings in said panel corresponds to commands to said virtual machine;
(b) means for generating a display in accordance with one or more user selected settings substantially contemporaneously with the selection thereof;
(c) means for storing information in a database, said information being representative of a plurality of said one or more user selected settings; and
(d) means for building one or more web pages for generating said website from at least a portion of said database and at least one run time file, where said at least one run time file utilizes information stored in said database to generate virtual machine commands for the display of at least a portion of said one or more web pages.
Description
FIELD OF THE INVENTION
The present application is directed to computing systems, and more particularly to methods and apparatus for building a web site using a browser-based build engine.
BACKGROUND
Conventional web site construction tools operate on traditional operating system platforms and generate as output HTML (hyper text mark-up language) and Script Code (e.g., JavaScript). A browser draws a web page associated with the web site by interpreting the HTML and JavaScript Code. However, conventional mark-up and scripting languages include numerous inherent limitations. Conventional mark-up and scripting languages have not been designed for serious multimedia applications. They have almost no file handling ability and very little computational power. In addition, they are remarkably slow and inefficient.
As such it is virtually impossible to write a web publishing application in HTML and JavaScript. All conventional implementations must, and do, utilize a full-featured programming language, such as C++ or Visual Basic. Since the current popular browsers do not support these languages, by necessity, conventional web publishing applications run on platforms other than the World Wide Web (WWW) and its browsers. Therefore, at best, a conventional web publishing application can offer only a crude preview capability of what a real web page will look like.
Although C++ and Visual Basic are very capable languages, the conventional web publishing applications written in these languages are still necessarily limited by the limitations inherent in their form of output, which as described above is typically HTML and scripting code. As such, a conventional web publishing application written in one of these languages suffers from the severe performance problems inherent in these languages.
For example, HTML and JavaScript are incapable of reformatting text and scaling buttons or images dynamically. In addition, most conventional web publishing applications design a web page layout to fit into a 640 pixel wide screen. This means that the ability for higher resolution screens to display more data horizontally is lost. Since capability is wasted on the horizontal plane, unnecessary vertical scrolling may be required. Further, on higher output resolution devices (screens), unsightly extra white space or background may be prevalent.
SUMMARY
In one aspect the invention includes a Browser Based build engine that is written entirely in a web based full featured programming language (e.g., JAVA). A Browser Based Interface (the "Interface") between the web designer and the build engine is included. The browser-based interface can be written in the World Wide Web's (WWW) Hypertext Markup Language (HTML) and its Extensions (Dynamic HTML, JavaScript and Cascading Style Sheets). The Interface includes a unique set of communication techniques. One technique allows for effective two-way communications between a JAVA engine and JavaScript. Another technique allows for communications between a JAVA applet object inside a JavaScript window, with the JAVA engine, which permits the implementation of advanced intelligent interface objects, such as a "slider" or a "dial".
In one aspect the invention includes a screen resolution sensing mechanism that causes a build engine (i.e. build tools) to adopt its interface to the web designer's screen resolution.
In one aspect, the invention includes a multi-dimensional array structured database, that, in addition to storing the numeric and string data found in conventional databases, also stores multi-dimensional arrays of various multimedia objects. They include colors, fonts, images, audio clips, video clips, text areas, URLs and thread objects. The invention includes a run time generation procedure that creates a compressed web site specific customized run time engine program file, with its associated database and a build engine generated HTML shell file.
The invention can include web page scaling technology, so that when the web site/web page is accessed on the WWW, the web pages and all the objects within them can be scaled to the user's screen resolution and to the then current browser window size.
In one aspect, the invention includes a proprietary multi-level program animation model (threads) that responds to multiple user interactions and time sensitive operations simultaneously.
In one aspect, the invention includes a mechanism for the dynamic resizing of the build engine's web page size during various editing operations.
In one aspect, the invention includes techniques for creating browser based interface objects that visually and behaviorally are identical to those of the MS Window's standard.
Aspects of the invention can include one or more of the following features. A browser based build engine is provided that includes a browser based interface. The entire web site build process is WYSIWYG (what you see is what you get), with the web designer working directly on and with the final web page. The data produced by the build engine is processed and ultimately placed into a multi-dimensional array structured database, and stored in an external file. A run time generation procedure creates a compressed program customized run time engine file, with an associated database and a build engine generated HTML Shell File.
When the web site/web page is accessed on the WWW, web page scaling technology can be accessed to generate web pages that are scaled to the user's screen resolution. A technique is provided so that an applet's size (height and width) can be set in real time under the control of either the interface or the build engine. At the same time a multi-level program animation model (threads) is activated for user interactions and time sensitive operations.
The browser based interface technologies create a set of interface objects with a look and feel that is identical to that of MS Windows, yet includes technologies that equal or occasionally surpass those of high end word processors, desk top publishers, and image processing software programs, particularly in the areas of interaction, animation, and timeline technologies. The run time engine includes multimedia capabilities often rivaling the digital processing capabilities seen on television and in the movies.
Because of the implementation of a variety of performance and file reduction techniques, the entire run time environment can range from as low as 12K, and no larger than 50K. This depends upon the features selected by the web designer. Although the compressed image, audio, and/or video files must also be downloaded, with a reasonable web site design, web pages should load quickly. The initial run time environment is no larger than 25K, thus the initial web page should generally load in less than 2 seconds, and subsequent web pages in less than 1 second with a 56K modem, even with numerous image files.
The present invention provides a real time, dynamic linkage between JAVA and HTML including two-way communications, in real time, between JAVA and JavaScript.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing aspects and many of the attendant advantages of the invention will become more readily appreciated through the following drawings and their associated screen shots, referred to throughout the detailed description, wherein:
FIG. 1 is a flow chart depicting a prior art conceptual overview of how a user and a web browser interface.
FIG. 2 is flow chart depicting a conceptual overview of how a user interfaces with a web browser when implementing the present invention to construct a web site.
FIG. 3a is a schematic diagram showing the main components of a build tool in accordance with one implementation of the present invention.
FIG. 3b is a process flow diagram showing a build process in accordance with one implementation of the present invention.
FIG. 4a is schematic diagram showing the main components of a run generation tool in accordance with one implementation of the present invention.
FIG. 4b is process flow diagram showing a run time process in accordance with one implementation of the present invention.
FIG. 5 is a flow chart, with its attendant screen shot shown in FIG. 37, that depicts a detailed view of a build time initialization procedure in accordance with one implementation of the present invention.
FIG. 6 is a flow chart, with its attendant screenshots shown in FIGS. 38-48, that depicts a detailed view of the build time supported user input techniques and techniques for communication of data and status between the build engine and the interface in accordance with one implementation of the present invention.
FIG. 7a is a flow chart that shows an overview of the build time techniques for implementation of pop-up windows (usually called "dialog boxes" in MS Windows), the panel interface, and interface for color selection.
FIG. 7b is a flow chart, with its attendant screenshots shown in FIGS. 37-38, that shows a detailed view of the build time techniques for implementation of panel interface objects, including the menu bar, menus and sub-menus, the tool bars, status fields, interactive fields, and interactive pull down lists, in accordance with one implementation of the present invention.
FIG. 7c is a flow chart, with its attendant screenshots shown in FIG. 37 and FIG. 63, that shows a detailed view of the build time techniques for implementation of tabbed pop-up windows (also called "dialog boxes" in MS Windows).
FIG. 8 is a flow chart that shows a detailed view of the build time techniques for updating the internal databases and the setting of feature flags for run time optimization purposes.
FIG. 9 is a flow chart, with its attendant screenshot shown in FIG. 37, that shows a detailed view of the build time polling methods used to facilitate communication from the JAVA build engine to the interface.
FIG. 10 is a flow chart that shows a detailed view of the build time techniques for analyzing user input for error checking and data integrity.
FIG. 11 is a flow chart, with its attendant screenshot shown in FIGS. 38-41, that shows a detailed view of the build time methods for direct text entry at an arbitrary cursor position and text editor implementation methods.
FIG 12 is a flow chart, with its attendant screenshot shown in FIGS. 49-56, that shows a detailed view of the build time techniques for reading external image files, creating them on a web page, and then manipulating them through either direct mouse interaction or through the interface's panel/windows.
FIG. 13 is a flow chart that shows a detailed view of the build time implementation of text, button and image styles in accordance with one implementation of the present invention.
FIG. 14 is a flow chart that shows a detailed view of the video and audio processing in accordance with one implementation of the present invention.
FIG. 15 is a flow chart that shows a detailed view of the frame, table, forms, and draw objects processing and technology in accordance with one implementation of the present invention.
FIG. 16 is a flow chart that shows a detailed view of the build time methods for supporting various user interactions at run time.
FIG. 17 is a flow chart, with its attendant screenshots shown in FIGS. 57-58, that shows a detailed view of the build time methods for text button and image object animation.
FIG. 18 is a flow chart, with its attendant screenshots shown in FIGS. 59-60, that shows a detailed view of the build time methods for text button and image transformations.
FIG. 19 is a flow chart, with its attendant screenshots shown in FIGS. 61-62, that shows a detailed view of the build time methods for text button and image time lines.
FIG. 20 is a flow chart with its attendant screenshot shown in FIG. 63, that shows a detailed view of the build time web page transition animations and time lines.
FIG. 21a is a flow chart that shows a detailed view of file operations performed in accordance with one implementation of the present invention.
FIG. 21b is a flow chart that shows a detailed view of the view operations performed in accordance with one implementation of the present invention.
FIG. 22 is a flow chart that shows a detailed view of a dynamic web resizing process that is activated by the "Open" and "Web Site" commands under the "File" menu and the "Zoom" command under the "View" menu.
FIG. 23 is a screen shot showing a file selection window operation in accordance with one implementation of the present invention.
FIG. 24 is a flow chart showing a detailed view of an external database in accordance with one implementation of the present invention and also shows the security and optimization techniques that can be employed.
FIG. 25 is a flow chart showing a detailed view of a method for creating a customized and optimized run time engine in accordance with one implementation of the present invention.
FIG. 26 is a flow chart showing a detailed view of the methods for creating an HTML shell file in accordance with one implementation of the present invention.
FIG. 27 is a flow chart showing a detailed view of the methods for creating compressed CAB and JAR files in accordance with one implementation of the present invention.
FIG. 28 is a flow chart showing a detailed view of the technology for dynamic web page size creation in accordance with one implementation of the present invention.
FIG. 29 is a flow chart showing a detailed view of the methods for reading the multimedia database and generating the necessary objects in accordance with one implementation of the present invention.
FIG. 30 is a flow chart showing a detailed view of the methods for dynamically scaling the web page object(s) to different screen resolutions and window sizes in accordance with one implementation of the present invention.
FIG. 31 is a flow chart showing a detailed view of the methods for executing a multi-level web page and object thread architecture in accordance with one implementation of the present invention.
FIG. 32 is a schematic diagram that shows a detailed view of the web page transition animation architecture in accordance with one implementation of the present invention.
FIG. 33 is a schematic diagram that shows a detailed view of the parent object time line architecture in accordance with one implementation of the present invention.
FIG. 34 is a schematic diagram that shows a detailed view of the child object time line architecture in accordance with one implementation of the present invention.
FIG. 35 completes the flow chart begun at FIG. 31.
FIG. 36 is a flow chart showing a detailed view of the methods for responding to user interactions in accordance with one implementation of the present invention.
FIGS. 37-63 are screen shots of the user interface presented by the build process in accordance with one implementation of the present invention.
DETAILED DESCRIPTION
Referring to FIG. 1, in a prior art process for creating and displaying a web site, the user either directly writes HTML and Script Code providing user input at 1 or operates a related prior art product at 2, which generates the HTML and Script Code at 3. A separate file, with its attendant HTML and Script Code is uploaded for each separate web page in the web site at 4, which is then interpreted by a browser when accessed at 5.
FIG. 2 shows a process for creating and displaying a web site in accordance with one aspect of the invention in which, a user operates a build tool at 6, working directly with one or more of the final web pages in a full WYSIWYG mode. The build tool accepts the user input and creates a multi-dimensional embedded multimedia object database at 7. A run time generation process is then invoked to create the necessary run time files at 8 (including HTML shell, CAB/JAR files and a customized runtime engine) which are then loaded to a user's web site at 9. The web page(s), when viewed by a web surfer, are activated by the browser calling the customized run time engine at 10. The run time engine then begins to read the database and down load image, audio and video files, while simultaneously drawing the first web page for viewing or user interaction at 11.
Build Tool and Process
FIG. 3a shows a build tool 350 at the detailed component level. The build tool includes a build engine 352, interface 354, screen sensing mechanism 356, multi-dimensional array structured database 358, interface's database 360, web page scaling engine 364, time line engine 366 and installation Program 368. The operation and use of each of these components is described in greater detail below.
FIG. 3b is a flow of the build process executed by the build tool to create a web page/web site. Referring to FIGS. 3a and 3b, the process begins with an initialization (12) and continues through to a point where a web site has been defined and stored in the build engine's internal database (29).
The build tool 350 includes plural individual tools that are created and initialized at (12). The processes for creating and initializing build tools are described in greater detail below in association with FIG. 5. After the build tools are created and initialized at 12, the build tool 350 interacts with the user, receiving user commands (actions), for example, to build a web site. The build tool 350 processes user responses and communicates the same and status information to both the build engine 352 and interface 354 at 13. The processes for interacting with the user are described in greater detail below in association with FIG. 6.
In one implementation, the interface includes a panel (and its objects, including a menu bar, menus and sub-menus, tool bars, status fields, interactive fields and interactive pull down lists), pop-up windows (called "dialog boxes" in MS Windows), color and alert message interface technologies, built with HTML, Dynamic HTML (DHTML), JavaScript, and Cascading Style Sheets (CSS). Interface 354 responds to the user input and may display a pop-up window, update the interface objects, or display alert messages, as shown at 15. The operation of the interface 354 is described in greater detail below in association with FIG. 7a, FIG. 7b and FIG. 7c.
As the build engine 352 receives data and status information, it updates an internal database (part of multi-dimensional array structured database 358) and sets feature flags at 14. The processes for updating the internal database and setting flags are described in greater detail below in association with FIG. 8. To enable effective two-way communication between the interface and the build engine, polling technology is included as shown at 16. The details of the polling process are described in greater detail below in association with FIG. 9.
Whenever user input is received, the build tool 350 analyzes the input including error checking at 17. In one implementation, the input is analyzed and then processed by object type (class). The process for analyzing input to determine type is described in greater detail below in association with FIG. 10. In one implementation, the number of different object processing technology classes are four, and include direct text entry (18), image processing (19), video or audio files and links (21) and frames, tables, forms and draw objects (22). The build tool 350 processes the user input based on class. The processes invoked for direct text entry are described in greater detail below in association with FIG. 11. The processes invoked for image processing is described in greater detail below in association with FIG. 12. The processes invoked by the text button, paragraph, and image style technologies are described in greater detail below in association with FIG. 13. The processes invoked for processing audio and video files and channels are described in greater detail below in association with FIG. 14. The processes invoked for processing frames, tables, forms and draw objects are described in greater detail below in association with FIG. 15. When an image, text button or paragraph object is to be inserted in the web page, the current style that is selected in the panel defines the initial settings used when creating the object in the web page. As such, button, image and paragraph style setting and technology will be invoked at 20 depending on the user input. The processes invoked by the paragraph style setting and technology is described in greater detail below in association with FIG. 13.
After the input is processed as described above, a check is made to determine if one or more animation or transformation (interaction) techniques are to be invoked at 23. The run time engine provided in accordance with the teachings of the present invention support various user interactions, including support for numerous animation and transformation techniques, and both web page and object time lines. Depending on the user selections, one or more technologies may be invoked. In the implementation shown, the build tool 350 is configured to check to determine if the input data is related to plural technologies including: user interaction technology (24), animation technology (25), transformation technology (26), object time line technology (27) and web page transition animation technology (28). The processes invoked for user interaction technology are described in greater detail below in association with FIG. 16. The processes invoked for animation technologies are described in greater detail below in association with FIG. 17. The processes invoked for transformation technologies are described in greater detail below in association with FIG. 18. The processes invoked for object timeline technologies are described in greater detail below in association with FIG. 19. The processes invoked for web page transition animation technologies are described in greater detail below in association with FIG. 20.
After the build tool 350 has processed the user input, one or more file operations can be invoked at 29a. In one implementation, the file operations are "save", "save as", "new", "close", "open", "apply" and "web site". If "open" or "web site" are selected, the build tool 350 initiates the dynamic web page resizing process at 29c (See FIG. 22). If "save" or "save as" are selected, the build tool 350 initiates a run generation process (See FIG. 4 and FIG. 24). File operations "close", "open", and "new" can also initiate the run generation process, based on the state of the build process and user action.
At any time during the processing of user input, one or more view operations can be invoked at 29b. In one implementation, the view operations supported are "normal", "preview", "play", and "zoom" (at various zoom percentages). If any of the "zoom" levels are selected, the build tool initiates the dynamic web page resizing process at 29c (See FIG. 22). If the "preview" or "play" view operations are selected they will initiate the run time process (See FIGS. 28 through 36). FIG. 4a shows a run generation and runtime tool 370 at the detailed component level. The run generation and runtime tool 370 includes a run generation procedure 371, web scaling engine 372, a database 374 and a (web) page size generation engine 376 and run time engine 377 including a runtime user interaction engine 378, a runtime timeline engine 380 and a runtime drawing, animation, audio, and video engine 382. In one implementation, run time engine 377 includes plural engines, each of which may in themselves include plural engines.
FIG. 4b shows the run processes including methods for creating the run time files, including the external database, the web site specific customized run time engine, the HTML shell file, and the compressed CAB/JAR file. The run processes also include methods for scaling each web page to the web surfer's then current screen resolution and web browser window size. After a web page has been scaled, a run time engine executes a multi-level thread technology, which presents to the viewer web pages that can operate under time lines that may include animated transitions. Associated with the web page time lines can be object time lines that may define entrance, main and exit animations, transformations, and synchronized time lines for child objects. Each object can have multiple object states, responsive to various user interactions, which can result in numerous types of visual and audio responses and actions.
Referring now to FIGS. 4a and 4b, a run generation process 360 begins by invoking the run generation procedure 377. The run generation procedure 371 begins by creating the external database (part of database 374) at 30. The external database may include references to image, video and audio files, and video and audio channels. The process for creating the external database is described in greater detail below in association with FIG. 24. A customized and optimized run time engine (run time engine 377) is created at 31. The customized and optimized run time engine (run time engine 377) generates the web pages for the web site and is activated from the user's server. The process for creating the run time engine 377 is described in greater detail below in association with FIG. 25. The HTML shell file is created at 32, and then the CAB and JAR files are created at 33a. The HTML shell file includes JavaScript Code to activate and interrogate the page size generation engine 376, and to activate the entire runtime engine. The CAB and JAR files both include the runtime engine and database in compressed executable form. The CAB file(s) will be activated by the HTML shell file if it senses the browser as being Microsoft Explorer, otherwise it will activate the JAR file(s). The processes for creating the HTML shell file and the CAB and JAR files are described in greater detail below in association with FIG. 26 and FIG. 27, respectively. The run generation process portion of the run processes is completed as the HTML shell file and the CAB and JAR files are uploaded to the user's web site at 33b.
After the upload, the run time process 365 portion begins with the run time engine 377 invoking a web page size generation technology (engine) 376 at 34. The web page size generation technology can be used to determine the screen resolution and the current browser window size. The process for invoking and initializing the web page size generation technology is described in greater detail below in association with FIG. 28. The external database is read and the necessary objects generated at 35 from their stored external references. These objects include image, audio, and video objects. The processes for generating the necessary objects are described in greater detail below in association with FIG. 29. A web page generation and scaling technology (web page scaling engine 372) is then invoked at 36. The web page scaling engine 372 can be used to reformat and scale objects that had been placed in a web page during the build process. The processes employed by the web page generation and scaling technology are described in greater detail below in association with FIG. 30. The run time engine then, as necessary, executes a multilevel web page and object thread technology at 37 while the runtime user interaction portion 378 of run time engine 371 responds to user interactions at 38. The processes invoked by the multilevel web page and object thread technology are described in greater detail below in association with FIGS. 31-35. The processes invoked by the run time engine to respond to user interactions are described in greater detail below in association with FIG. 36.
Detailed Build Processes
Referring now to FIGS. 3a and 5 through FIG. 22 the build tool 350 and its associated build process are described. Referring first to FIGS. 3a and 5, initialization methods are shown. At 39 the build tools are created as part of the execution of the installation program 368. They can include:
1: Initial build tool HTML/JavaScript file (IBTF)
2: An initialization engine (IE).
3: A build engine.
4: The build engine parent HTML frame file. (PFF).
5: A "Control Panel and Status Line" HTML/JavaScript File ("panel") for;
Controlling the JavaScript database.
Calling and initializing all pop-up windows.
Reading all pop-up window values, and updating a JavaScript database
Calling the build engine and passing all necessary data and status information.
Polling the build engine for two-way JAVA/JavaScript communication.
Displaying and updating the status of its interface objects.
Issuing alert messages.
Processing direct user interactions with the panel's interface objects.
6: Numerous HTML/JavaScript files, one for each pop-up window.
7: JAVA applets, embedded in HTML/JavaScript pop-up window files.
8: A build engine HTML definition file that is created and modified dynamically.
The initialization and build engines can be placed in a JAVA wrapper so that JavaScript code may receive and process return values from JAVA methods. The initialization and build engines are also created in a "Signed" CAB file, and assigned the necessary security rights, so that the engines can assert the necessary permissions, if permitted by a given browser's security manager, when read or write operations are required. In one implementation, an installation program is run prior to the first use of the build tools. After installing all of the files, the installation program can install the necessary class libraries required by the run generation process in which the customized and optimized run time engine is created (See FIG. 25). The installation program can also set the necessary environmental variables and installation options.
At 40 the web surfer points a browser at (i.e. calls) an initial build tool HTML/JavaScript file (IBTF). At 41 the IBTF identifies the current browser type and version number. Presently, each browser has different security manager implementations. In one implementation, the invention supports the following three categories:
1: With appropriate signing and time stamping, and with appropriate assertions of permissions, the browser will permit local read/write operations.
2: With appropriate signing and time stamping, and with appropriate assertions of permissions, the browser will permit local read operations, but write is only legal if sent to a server.
3: Local read/write operations are illegal, but are permitted on the server. The IBTF can include a flag that can be set to indicate which security implementation is supported, so that all subsequent read/write operations will comply with the current browser's security manager.
At 42, the IBTF causes the browser to execute the IE so as to sense the screen resolution and for adapting the interface to the user's screen resolution. In one implementation, after entering a delay loop and waiting for the IE to report it is fully loaded and initialized, the IBTF calls two IE methods, which return the width and height of the current screen and browser window. The IBTF then checks for the presence and value of a "mode cookie", to determine whether this is an initialization process, a web site open command process, or a dynamic web page resizing process. If the mode cookie is set to initialize, or it doesn't exist, the IBTF calls the IE to generate the build engine's HTML definition file. At 43 the IE then asserts the required security permission and at 44 creates a build engine HTML definition file and writes this file to the local disk (as appropriate). At 45 the IBTF then turns control over to the PFF for activating the "paner" and build engine and displaying the build engine user interface screen.
The build engine user interface screen includes a "panel" portion and a build engine portion, each of which are loaded into their respective frames, after which the web site page(s) build process can begin. Screen shot FIG. 37 shows a representation of the user interface presented by the build tool. The user interface includes a panel 400 and build frame 500. Panel 400 includes a menu bar 410, menus 420 and sub-menus 430, tool bars 440, status fields 450, interactive fields 460, interactive pull down lists 470 and operational pop-up windows 480. The menu bar 410 can be used for selecting a menu command that will cause a menu to be drawn. The menu (one or menus 420) can be used to select a feature command that could cause an operational pop-up window to be drawn, a direct user input technique or object manipulation technique to be activated, or a sub-menu 430 to be drawn. A sub-menu (one of sub-menu 430) can cause the same type of events as that of a menu. The tool bars 440 include various icons that are shortcuts to feature commands that are also available through the menu bar and its menus. In addition, the tool bar 440 can be used to show the current state of a feature. Status fields 450 show the current value of a certain setting. Interactive fields 460 also show the current value of a setting, but can also be directly changed by the user by typing into the field, with the result immediately processed by the build engine 352 and displayed in the build frame 500. Interactive pull-down lists 470 also show the current value of a setting, but, if selected with a mouse click, will drop down a selection list, which may have an elevator attached. The user can click on an item in the selection list, which will become the current setting with the result immediately processed by the build engine 352 and displayed in the build frame. Operational pop-up windows 480 can have tabs assigned if the number of choices within the pop-up window is large. One or more settings can be changed through a pop-up window, with the results immediately processed by the build engine 352 and displayed in the build frame 500. These interface techniques are described in greater detail below in the build process.
The build frame 500 is used to present the actual web page as constructed by a user. The user can directly enter text, import images, video and audio for display/playback and create animations and transformations that can be viewed in the build frame. FIG. 6, with its attendant screen shots FIG. 38 through 48, shows the user input techniques supported in one implementation of the invention. In one implementation, the user inputs supported include: selection from a JAVA window object (48); selection from a JavaScript window (49) including selection with dual spin control (50a) or selection from a JavaScript child window object (50b); direct text entry (51); page resizing (52); direct object manipulation (53); and, selection from a JavaScript panel (54).
In the implementation shown, of the six user input techniques sensed at 13, the code for supporting selections from a JavaScript pop-up window at 49 and selections from the "panel" at 54 were implemented entirely in HTML/JavaScript Code, while support for direct text entry at 51 and direct web page object manipulation at 53 were implemented entirely in JAVA (or any other browser-based full featured programming language). In one implementation, code for supporting selections from a JAVA Window object at 48 and dynamic web page resizing at 52 are implemented using both HTML/JavaScript and JAVA. Those of ordinary skill will recognize that, JAVA could have been used more extensively to implement the methods described at 48, 49 and 54. However, in order to achieve the most intuitive and MS Windows like interface, and because effective two-way communication between JavaScript and JAVA had been achieved (See FIG. 9), the languages proposed appear to best support the particular user input technique.
For example, FIG. 23 shows an actual file selection window 2300, implemented by the invention. This type of file selection window is available in JavaScript/HTML, but not supported by JAVA for applets. File selection window 2300 greatly enhances the interface for the user, as the image, sound clip, or video clip names need not be memorized. File selection window 2300 further eliminates possible operator error when typing in a pathname or filename. The present invention utilized the strengths of JavaScript/HTML with the power of JAVA to create a unique browser based interface solution. In one implementation, the HTML form element "INPUT type=file" was embedded in a JavaScript pop-up window to create the file selection window. The file selection window returns a string value of the image (or other file type) pathname to the pop-up window. The pop-up window's JavaScript then could be used to call a JavaScript function in the panel (panel 400) which:
1: Reads the pathname value in the pop-up window.
2: Creates a string version of a valid URL by adding the correct URL protocol to the string.
3: Updates the panel's database (interface's database 360).
4: Calls a JAVA method in the build engine, which casts the string value of the URL into a URL object, creates an image object which is then drawn on the screen, and updates its internal database.
User inputs that are a selection from a JAVA window object (48) permit the implementation of a vast array of intelligent user input interface objects, from sliders to dials, which are extremely intuitive and significantly enhance the user's ergonomic experience. In one implementation, user input interface objects are supported as follows. When a selection from a JAVA window is detected, a pop-up window (applet) is presented (associated with the feature being manipulated, e.g., color, volume) and an engine method is called to begin two-way communication (for passing as arguments any necessary status information). The engine begins polling a JAVA abstract object waiting for a static variable's value to change. The pop-up applet processes the value as defined by a user interaction event, and updates the static variable in that same JAVA abstract object with the new value. Upon detecting a change in the polled static variable, the engine calls the necessary methods to process that new value. These methods include can include a brightness filter that is applied to the image bitmap utilizing techniques very similar to that of that employed by the "fade in" and "fade out" animations, described in association with FIG. 33
User inputs for a selection from a JavaScript pop-up window (49) can be made in a manner identical to that of making a selection from a dialog box under MS Windows, including the use of tabbed JavaScript pop-up windows. In one implementation when a selection from a JavaScript pop-up window is detected, the panel's (panel 400) JavaScript opens a pop-up window. The pop-up window's initial values are set from a JavaScript database defined in the panel or by the panel calling the engine for the current values and then setting the initial values. In a tabbed JavaScript window, clicking on a tab will call the pop-up window's JavaScript in order to change the state and appearance of the tabbed JavaScript window in the expected way. The pop-up window's JavaScript calls the panel's JavaScript when a completion event occurs. The panel's JavaScript reads or the pop-up window's JavaScript writes the pop-up window's field values, causing the panel's database to be updated, and the panel then calls the appropriate build engine 352 method, passing as arguments the necessary data and status conditions. Initializing the pop-up window's values and updating the panel's database upon completion can alternatively be implemented by JavaScript functions executed within the pop-up window's HTML file.
In addition, there are interface extensions that can extend beyond the usual MS Windows implementations. One is support for a selection from a dual spin control at 50A. Screen shots FIGS. 42-45 show a visualization of an implementation of this interface technique. Screen shot FIG. 42 shows the mouse placed over an upper spin control. Screen shot FIG. 43 shows the result after the user clicked once on the upper spin control. Notice that the value has been incremented by 1, and the text button object is now at a larger point size. Screen shot FIG. 44 shows a combo box list selected by the mouse with the user about to select a significantly larger point size. Screen shot FIG. 45 shows the result of that selection, including the effect on the text button object.
In one implementation, dual spin controls are supported as follows. Each spin control has three visual states, so that when the user places the mouse over the control it appears to light up, and when the mouse button is depressed (pressed down), the spin control is modified to give the appearance of being pressed. JavaScript methods are called in the panel (panel 400) to:
1: process each mouse click event over either spin control,
2: range check as necessary,
3: update the value in the HTML frame object residing in the pop-up window,
4: update the JavaScript (panel 400) database,
5: call the build engine 352, if necessary, passing the necessary value and status.
If the mouse is clicked on a combo box, the selection window opens in the usual way. If a mouse click in that window is detected, another JavaScript method in the panel 400 is called to update the JavaScript database, and call the build engine 352, if necessary, passing the necessary value and status as function call arguments.
Another interface extension is selection from a JavaScript child window at 50B. This technique helps simplify the number of choices given to the user in a complex pop-up window operation. A selection from a JavaScript child window can be supported as follows. The panel's (panel 400) JavaScript opens the pop-up window. The pop-up window and its child pop-up windows' initial values are set from the JavaScript database defined in the panel 400. The pop-up window's JavaScript opens the child pop-up window and sets its initial values. The child pop-up window's JavaScript calls the pop-up window's JavaScript when a completion event occurs. The pop-up window's JavaScript reads the child pop-up window's values, sets those values to its own internally defined variables, and calls the panel's JavaScript. The panel's JavaScript reads the pop-up window's values (which include the settings for its own fields as well as those of its child windows), updates its database, and calls the appropriate build engine 352 method, passing as arguments the necessary data and status conditions. Screen shots FIGS. 46-47 show a visualization of an implementation of a JavaScript child window. Screen shot FIG. 46 show a change text button style pop-up window. Screen shot FIG. 47 shows the result after the user selected the "Define the Mouse Down Text Button Style" child pop-up window.
Direct text entry is supported at any arbitrary cursor location. In one implementation, "text areas" are utilized in an unconventional way, in order to support full text entry, text editing, text button and paragraph styles, and reformat. Direct text entry can be defined at any arbitrary cursor location, and then text can be dragged to any other arbitrary location.
Text areas are objects that are utilized by JAVA primarily as an interface object for the implementation of a form and are generally "added" to the screen at the initialization time of a JAVA applet. Text areas are decidedly not WYSIWYG. The present invention creates text areas dynamically. Screen shots FIG. 38 through FIG. 41 show a visualization for an implementation of this technique. Screen shot FIG. 38 shows the user selecting a text object from the create text icon object from a tool bar of the panel (panel 400). When the text icon object is selected, the cursor shape is changed to indicate the selection while the text icon object is in the select state. Screen Shot FIG. 39 shows that the cursor has changed shape and that the user has placed the cursor at an arbitrary location on the web page. Screen shot FIG. 40 shows the result after the user has clicked the mouse. A text insertion point and a selection rectangle are drawn at the arbitrary web page location. Screen shot FIG. 41 shows the result after the user has pressed the letter "W" on the keyboard. As can be seen in screen shot FIG. 41, a draw method associated with the build process immediately hides the text area. However, text editor methods associated with the build process continue to utilize the text area as a hidden, dynamically resizing frame, whose size is subject to text button or paragraph style settings, by the amount of text, by the text's orientation (vertical or horizontal) and by the text's font style(s) and font size(s). As the build engine 352 detects a relevant mouse event or keyboard event, the build engine 352 updates the necessary variables that are defined as return values in specified build engine methods. Polling technology (see FIG. 9) retrieves the relevant values and calls the necessary JavaScript method for processing. In one implementation, these same techniques (text area techniques) are used in the scaling technology (See FIG. 30). Since the direct text entry and editing processes bypass completely the interface and the JavaScript code, the polling technology (See FIG. 9) is used to pass the text string values back to the JavaScript database, in order for the interface's pop-up windows to be correctly initialized for subsequent text operations.
Direct text processing at 51 begins with the build engine 352 detecting a "Mouse Drag" or a "Mouse Double Click" event. In one implementation of the present invention, if a mouse drag event is detected, the entire initial anchor word (assuming the "mouse down" event placed the text insertion point within a word) is selected as well as the entire closing anchor word. If a double click event occurs over a word, the entire word is selected. If a double click event is detected over a special hot zone (for example, just to the left of a paragraph line), then an integral number of words are selected. Appropriate four-dimensional variables are set, and a draw system is called. The draw system paints the selected line segment in the marked text background and text color. The build engine 352 then sets a return flag to be read by the polling technology (FIG. 9). A panel JavaScript poller (FIG. 9) detects this flag and redraws the panel's "Text" menu object showing the choices available when text is selected. In one implementation, the "Text" menu includes choices of "Text Style", "Hot Link", "Preferences", and "Format". The states for the tool bar icon objects of "Bold", "Italic" and "Underline" are set appropriately as is the setting for the point size interactive drop-down list. The panel's JavaScript then calls an appropriate build engine method that resets the flag. If the panel's JavaScript detects the user selecting the "Text Style", "Hot Link", "Preferences" or "Format" choices, it creates the appropriate pop-up window. Upon detecting a user completion event, the panel's JavaScript reads the data settings in the pop-up window, closes that pop-up window, and sends this data to an appropriate build engine method for processing (See FIG. 11). Dynamic web page resizing at 52 is invoked when the build engine 352 detects a user initiated web page resize event. This could be caused by the "Open" or "Web Site" commands from the "File" menu, or from a "Zoom" command from the "View" menu. This technology is explained in detail below in association with FIG. 22.
Direct object manipulation at 53 includes dragging of any object, resizing of non-text objects, rotation and other image manipulation functions, as required. The processing for direct object manipulation begins by analyzing the type of object selected and the state of the object, as set by the interface based on a user's panel selection. The build engine 352 then changes the mouse cursor's appearance, and the type of selection rectangle, including which attachment points, if any, should be drawn and activated. (See FIG. 10 for the mouse event processing technology and FIG. 12 for image processing technology). In one implementation, the same direct object manipulation polling technology is used as described above with regard to direct text entry.
If a selection of an interactive field, interactive drop-down list object, or a toll bar icon object from the JavaScript panel is detected at 54, then the following steps can be invoked, depending on the selection. The point size of a paragraph, a marked text range inside a paragraph or text button object can be changed. The state of an object's 3D frame can be changed. In one implementation, three states for an object frame are supported. The 3D frame can be drawn as a "raised" 3D object, as a "depressed" 3D object, or as a "raised" 3D object that turns into a "depressed" 3D object if a mouse down event is detected over the object to which the 3D frame is assigned. An object's style can be changed. The current web page can be changed. Finally, any other operation that has been defined by a tool bar icon object in the panel can be invoked. This includes the "file" menu choices of new, open and save, the "edit" menu choices of cut, copy and paste, inserting a text, button or image object onto the web page, applying or removing the bold, italic, and underline text attributes for a text or button object, centering or uncentering any web page object, setting the animation for a button or image object, changing the zoom level of the web page, or previewing the web site.
As each new user input is received and processed in accordance with the steps shown in FIG. 6, at all times the internal databases of the JavaScript panel and the build engine 352 are maintained completely in synchronization. Synchronization is maintained so that: all status information displayed by the panel is current and correct; all data and status information passed to the build engine 352 from the interface are consistent with the build engine's state at any given time; the values in all pop-up windows are correctly initialized. In order to meet these requirements, all of the variables in the JavaScript panel database are explicitly "typed", to be compliant with the strict variable typing methodology generally imposed in all full featured programming languages such as Java. As JavaScript does not explicitly type anything, where using JavaScript herein, all string, Boolean, and integer variables are typed. Full two-way real time communication support between the JavaScript/HTML interface and the JAVA build engine 352 is provided as described below in association with FIG. 9.
FIG. 7a shows four tools utilized for an implementation of the pop-up window and panel interface technology (15 of FIG. 3). The panel and pop-up windows make extensive use of JavaScript mouse events, including onMouseDown, onMouseUp, onMouseOver, onMouseOut, onClick and onchange methods (56). The pop-up windows make extensive use of the JavaScript onLoad and onUnLoad methods. In one implementation, when a pop-up window is loaded by the panel, the panel goes into a wait loop, set for 5 times a second using the JavaScript setTimeout method, interrogating in each loop whether the pop-up window's status flag has been set. Meanwhile the pop-up window, when loaded by the browser, executes the onLoad method in order to set a flag in the panel informing the panel that the pop-up window is now loaded. Upon detecting the load event completion, the panel then proceeds to initialize the fields in the pop-up window. The panel will always close a pop-up window after detecting its completion event. However, if the user has closed the pop-up window in a non-standard way, the pop-up window executes the onUnLoad JavaScript method, which sets a flag in the panel notifying it that the pop-up window has been closed.
The JavaScript code in the panel and in all pop-up windows make extensive use of JavaScript method onKeyDown for the following operations:
1: When the focus is on the icon representing completion ("OK" is used in many MS Windows applications) causing the enter key to initiate a pop-up window/panel completion event.
2: When the focus is on the icon representing cancellation ("cancel" is used in many MS Windows applications) causing the Esc key to initiate a pop-up window/panel cancellation event.
3: When the focus is on any pop-up window or panel object, such as a data entry field, a check box, a radio button, a drop-down and scrollable list, a scrollable list, an icon, or a DHTML tab object (discussed below), the navigation keys are captured by the onKeyDown method, a JavaScript function is called, and the appropriate change is made. For all pop-up window and panel objects, when the Tab key or the combination of the Tab key with the Shift key are detected, the onFocus JavaScript method is employed and the focus moves to the appropriate pop-up window object. If the pop-up window or panel object is a data entry field, drop-down list or a scrollable list, all cursor key operations are detected and the insertion point is adjusted accordingly. If the pop-up window or panel object is a check box, radio button a icon, or a DHTML tab object, and a cursor key (up, down, left, right, home and end keys, with or without the Ctrl or Shift keys) is detected, the onFocus JavaScript method is employed and the focus moves to the appropriate pop-up window object.
One methodology for this feature requires that all keyboard events be monitored, at all times. When the scan code for the enter key is detected, the appropriate JavaScript function is called to close a pop-up window and to call the appropriate JavaScript function for processing of the relevant data (updated in the window) and communicating, as necessary, with the build engine 352. In another implementation, rather than the panel going into a wait loop awaiting notification from the pop-up window for data initialization purposes the pop-up window, when loaded, executes the onLoad JavaScript method, and reads the required data values directly from the panel's database, utilizing the JavaScript "opener.fieldname.value" technique. Similarly, the pop-up window, when detecting its completion event, updates the panel's database with the revised values from its own fields and then calls the appropriate JavaScript function in the panel for further processing. Both implementations, and any combinations, assure that the pop-up windows are correctly initialized, the panel's database is correctly updated, and the data is successfully sent to the build engine 352 for processing.
Extensive use of JavaScript technology is employed to enhance the user interface and for communication between the various HTML frames and/or files, within a given HTML frame or file, between an HTML frame and the JAVA engine, and as a bridge between two different JAVA applets (57). Extensive use is made of JavaScript arrays to store the values of all page and object attributes, to initialize the correct values in all pop-up windows, and to pass data and status to the engine. Various JavaScript techniques are employed to "type" all variables (JavaScript does not explicitly type anything as described above) as a prerequisite for passing values to the build engine 352. Variables that should be typed as strings, integers and Booleans are typed through the use of "Eval" and "New" JavaScript functions. The choice of color, found in most pop-up windows to define one or more color elements, can be implemented utilizing several innovative JavaScript techniques. They include:
1: Defining a complex image map through a JavaScript function utilizing arrays. Screen shot FIG. 48 shows a visualization of an image map. A JavaScript computational loop utilizing arrays can be used to define each individual rectangle in this color palette with its appropriate RGB value and a function call to the appropriate JavaScript method.
2: Limiting the color choices from the image map to only those colors that are designated as safe colors. Safe Colors are the subset of all colors that are browser independent, assuring a consistent color look across all browsers.
3: Supporting a dual color selection technology. The user can be presented with a color palette and can click on a particular color in the color palette. Image map technology can call a JavaScript function, which converts that choice into a RGB numeric definition. This definition updates the RGB values shown in screen shot FIG. 48, as well as passing those values, though an appropriate function call, to a build engine JAVA method. The build engine 352 will then draw the actual color immediately on the web page. Alternatively, the user can select a value from Red, Green or Blue selection lists, which can be implemented using an HTML drop-down list form object. The value selected is then processed by an appropriate JavaScript function call to a build engine method, which converts the RGB to a JAVA compliant value, and then draws the actual color on the web page.
4: Supporting True Transparency. For appropriate color elements, such as the background for a text button object, the user can choose, either from the color palette by clicking on a "transparency" rectangle, as described above, or by selecting "TIR" from a Red, Green or Blue selection list. This choice is then processed by an appropriate JavaScript function call to a build engine method, that in turn sets a particular flag for the draw system (of the Build Tool) to not draw a background color for that object.
Innovative techniques are used to enable JavaScript to dynamically create HTML code based on real time conditions. Cookies can be used for data communication between HTML frames and HTML files, some of which were created in real time. Many unique combinations of HTML elements, including frames, forms, and tables, enhanced by JavaScript code, are utilized to create a extensions beyond that of the MS Windows interface (58). For example, a dual combo box/spin control for both small and large numeric incremental jumps can be implemented by a combination of form and table elements, mouse events, and JavaScript methods.
Extensive use of Cascading Style Sheets (CSS) was employed to create a consistent look for all pop-up windows, and for precision placement of various HTML elements (59).
FIG. 7b shows a detailed view of the build-time techniques for implementation of panel interface objects, including the menu bar, menus and sub-menus, the tool bars, status fields, interactive fields, and interactive pull down lists, in accordance with one implementation of the present invention (15 of FIG. 3). These techniques create panel interface objects that have the same look and feel of those which are implemented under the various MicroSoft Windows Operating Systems. In one implementation of the present invention, the status fields, interactive fields, and interactive drop-down lists are defined as HTML form objects (text boxes and lists) embedded within DHTML objects. The menu bar, menus and sub-menus, and the tool bars can be defined as pure DHTML objects. However, Cascading Style Sheets can be used for all panel interface objects; although more extensively with DHTML objects as will be described below. In an alternative implementation of the present invention, the status fields and interactive drop-down lists are defined as pure DHTML objects.
In one implementation of the present invention the menu bar at 270 is defined as sets of DHTML objects, each set corresponding to a menu command. Each set consists of four DHTML objects with absolute screen positioning, one defining the DHTML object in the Mouse Over state at 278, the second for the Mouse Down state at 279, the third for the Active state, and the fourth for the Inactive state. Each state has a different CSS style assigned, which defines the visual appearance of that state. When the build tool is initialized at FIG. 5, the appropriate menu commands are initialized as active or inactive at 277. If the menu command is defined to be inactive, that DHTML inactive object is assigned by a JavaScript function to the "visible" style attribute, while the other three DHTML objects are assigned the "hidden" style attribute. Screen shot FIG. 38 shows a visualization of the "Interactions" menu command in the inactive state. In the inactive state all user interactions are ignored. If the menu command is defined to be active, that DHTML active object is assigned by a JavaScript function to the "visible" style attribute, while the other three DHTML objects are assigned the "hidden" style attribute. While in the active state, the JavaScript functions for "onMouseDown", "onMouseUp", "onMouseOver" and "onMouseOut" are implemented. If a Mouse Down user interaction event is detected over an active menu DHTML object at 279, a menu command specific JavaScript function is called. This function sets the DHTML object for the Mouse Down state to the "visible" style attribute, calls a generalized JavaScript function to reset the visibility states all the other appropriate DHTML objects, set certain status variables, and set the DHTML object which defines the menu associated with that menu command to the "visible" style attribute. Screen shot FIG. 37 shows a visualization of the "Image" menu command after having received a mouse down event, with its associated menu 420 having been set to the "visible" style attribute. If a mouse up user interaction event is detected over an active menu DHTML object at 281, a generalized JavaScript function is called in which the DHTML object defining the mouse over state is passed as a function call argument. This function sets the DHTML object defining the mouse over state to the "hidden" style attribute thus resulting in the appearance as shown for the image menu command in screen shot FIG. 37, even when the mouse has been moved off the menu object. If a mouse over user interaction event is detected over an active menu DHTML object at 278, a generalized JavaScript function is called in which three DHTML objects are passed as function call arguments as well as a menu command name. These DHTML objects are the ones defining the mouse over state, the mouse down state, and the associated menu. This JavaScript function first tests to see if a menu has been activated by a previous mouse down event and is still visible. If so, a generalized "reset visiblity states" function is called, then both the mouse down and associated menu objects are set to visible. Finally the same menu specific function is called as with the mouse down event. If no menu is visible, then the object associated with mouse over state is set to visible. If a mouse off user interaction event is detected over an active menu DHTML object at 281, a generalized JavaScript function is called in which the mouse over DHTML object and the menu command name are sent as arguments. Logic tests are made to determine which menu command object has been left, as well as whether any menus are currently visible. Depending upon the results, the mouse over DHTML object may be set to hidden.
In one implementation of the present invention the menus and sub-menus at 271 are defined as a set of DHTML objects, one for each menu choice, nested inside an DHTML object that defines the entire menu. Each menu object is given absolute positioning, while the menu items are given absolute positioning relative the menu objects origin. Both the entire menu and each choice are assigned CSS styles to define their visual appearances. For each menu choice the JavaScript functions for "onClick", "onMouseOver" and "onMouseOut" are implemented. If a mouse click event is detected at 280 and no sub-menu is defined, a feature specific JavaScript function is called. First the menu bar and the menus are set to their appropriate visibility states. Then setting their visibility attribute style to "visible" activates the appropriate tool bar icon DHTML objects. Finally the feature specific JavaScript code is executed as discussed herewithin, which may cause a pop-up window to be displayed, the Panel's database to be updated, and/or the build engine 352 to be called. If a mouse over event is detected at 278 and no, sub-menu is defined, a generalized JavaScript function is called in which the menu choice object is passed as an argument. This function first calls a generalized JavaScript function to close any pop-up windows, then set a status variable and finally executes DHTML commands to set the correct text and background colors for the object. If a mouse off event is detected at 282 and no sub-menu is defined for a menu choice either immediately above or below, a generalized JavaScript function is called in which the menu choice object is passed as an argument. A status variable is set and DHTML commands are executed to set the correct text and background colors for the object. If a sub-menu is defined for a menu choice object, then the same sub-menu specific JavaScript function are called for both mouse click or mouse over events. This function performs the same steps as that of the generalized function that was called for a mouse over event, as well as setting the sub-menu object and its menu choice objects to the visible state. Screen shot FIG. 37 shows a visualization of the menu bar's "Image" command having been activated, the drawing of its associated menu 420, the selection of the "Enhance" menu choice, and the drawing of the "Enhance" sub-menu 430. In the event that the cursor is moved to an adjacent menu choice under the "Image" menu, such as "Animation . . . " or "Rotate", then a specific JavaScript function is called which, in addition to the functions executed by the generalized JavaScript mouse over function, also hides the "Enhance" sub-menu.
In one implementation of the present invention, the tool bars at 272 are defined as a DHTML objects, and a set of DHTML objects are defined for a tool icon. The tool is given absolute positioning and is assigned a CSS style in order to define is visual appearance. Each tool icon is assigned a set of three DHTML objects all with absolute screen positioning. The first DHTML object defines the mouse over state at 278, the second for the mouse down state at 279, and the third for the active state. Each state has a different CSS style assigned, which defines the visual appearance of that state. For each tool icon active state object the JavaScript functions for "onClick", "onMouseDown", "onMouseUp", "onMouseOver" and "onMouseOut" are implemented. GIF images are defined for the tool bar DHTML objects, and may be always visible. The inactive "grayed out" representations for each toll icon can be drawn on this image. When the build tool is initialized at FIG. 5, the appropriate tool icon objects are defined as active or inactive at 277. The inactive state for an tool icon is represented when all three of its associated objects are assigned the visibility style of "hidden". Screen shot FIG. 38 shows a visualization for several inactive tool icons including the icon commands for bold, italic, underline, left and centered. All user interaction events are ignored in the inactive state. If the tool icon, based on the state of the build engine and based on the polling technology described below, is set to an active state, then the tool icon's active state object is set to the visibility style of "visible". If a mouse click event is then detected at 280, a feature specific JavaScript function is called in a manner identical to that for a mouse click event over a menu choice object as described above. If mouse down or mouse up events are detected at 279 or 281, then respective generalized JavaScript functions are called, in which the DHTML object defining the mouse down state is passed as a function call argument. If a mouse down event was detected, then the generalized function sets the tool icon's mouse down object to the "visible" state. If a mouse up event was detected, then the generalized function sets the tool icon's mouse down object to the "hidden" state. If mouse over or mouse out events are detected at 278 or 282, then respective generalized JavaScript functions are called, in which the DHTML object defining the mouse over state is passed as a function call argument. If a mouse over event was detected, then the generalized function sets the tool icon's mouse over object to the "visible" state. If a mouse off event was detected, then the generalized function sets the tool icon's mouse over object to the "hidden" state. Screen shot FIG. 37 shows a visualization of the button tool icon with both its associated the mouse down and active objects set to "visible". Screen shot FIG. 38 shows a visualization of the text tool icon with both its associated the mouse over and active objects set to "visible".
In one implementation of the present invention, the status fields at 273 and the interactive fields at 274 are defined as HTML text boxes. In an alternative implementation status fields are defined as DHTML objects. For both of these panel interface object types, under certain conditions, the panel draws status information into these panel interface objects. This information can result from user input as discussed in FIG. 6, or through the polling and two-way communication technology between the interface and the build engine 352 as discussed below. In one implementation of the present invention the status fields are:
1: The color of the selected web page object, in which the red, green and blue settings are shown.
2: The animation state of the selected button or image object.
3: The zoom level for the current web page.
4: The point size for the selected text or button object.
5: The horizontal position, in pixels, of the mouse cursor.
6: The vertical position, in pixels, of the mouse cursor.
7: The type of web page object (text, button, image, table, form object, draw object, etc.,) if selected. The type of object that the mouse is over, if no object is selected.
8: The width, in pixels, of web page object (text, button, image, table, form object, draw object, etc.,) if selected. The width of the object that the mouse is over, if no object is selected.
9: The height, in pixels, of web page object (text, button, image, table, form object, draw object, etc.,) if selected. The height of the object that the mouse is over, if no object is selected.
Screen shot FIG. 38 shows a visualization of the status fields in one implementation of the invention 450. In an alternate implementation using DHTML objects, the status fields will appear two-dimensional rather than the three-dimensional look currently shown.
There is one interactive field defined in one implementation of the present invention. Screen shot FIG. 37 at 460 shows a visualization of the page number interactive field. In addition to the current web page being displayed, either as a number in one implementation or as a user defined name in an alternative implementation, the user can place the cursor into this field and enter the desired page to go to. A click at 280 or Enter Key event will execute this function.
In one implementation of the present invention, the interactive drop-down lists at 275 are defined as HTML form lists. In an alternative implementation, status fields are defined as DHTML objects. For both of these panel interface object types, under certain conditions, the panel draws status information into these panel interface objects. The interactive drop-down lists behave in a manner very similar to that of interactive fields, except that when selected, a selection list drops down for selection. Depending upon the number of entries in the list, an elevator object may be drawn. The operations of selecting the interactive pull down list, the selecting of a list item, or the operation of the elevator is identical to that of comparable MS Windows objects. In one implementation of the present invention the interactive pull down list are:
1: Zoom. This interface object has dual spin controls as described above and is always selectable except when in a preview mode. It shows the current zoom level.
2: Button Style. This interface object is always selectable except when in preview. It shows the button style of the currently selected button, if any. Changing the button style will change the style of the currently selected button, and/or define the style of the next button to be created.
3: Point Size. This interface object has dual spin controls as described above and is selectable when a text or button object is selected. It shows the point size of the currently selected text or button object, if any. Changing the point size will change the point size of the currently selected text or button object.
4: Paragraph Style. This interface object is always selectable except when in preview. It shows the paragraph style of the currently selected paragraph, if any. Changing the paragraph style will change the style of the currently selected paragraph, and/or define the style of the next paragraph to be created.
5: Frame State: The state of the 3D frame (none, raised, pressed or live) of the currently selected text, button, or image object.
6: Image Style. This interface object is always selectable except when in preview. It shows the image style of the currently selected image, if any. Changing the image style will change the style of the currently selected image, and/or define the style of the next image to be created.
Screen shot FIG. 37 shows a visualization of interactive drop-down lists 470. In an alternate implementation using DHTML objects, the interactive drop-down lists will appear two-dimensional rather than the three dimensional look currently shown.
Tool bar icon objects, status fields, interactive fields, and interactive pull down lists all show feedback of the current build engine state. The technology utilized by one implementation of the invention is described below.
FIG. 7c shows a detailed view of the of the build time techniques for implementation of tabbed pop-up windows (15 of FIG. 3). These techniques create a pop-up window interface that visually and behaviorally is identical to that which is implemented as dialog boxes under the various MicroSoft Windows Operating Systems. Pop-up windows can be non-tabbed as described in FIG. 7a, or can have from two to as many as 10 or more tabs, depending upon the complexity of the choices available to the user for a given feature. In one implementation of the present invention each tab at 283 is defined as a DHTML object at 284. The tab is given absolute positioning and is assigned a CSS style at 286 in order to define is visual appearance. When a click is detected through the JavaScript "onClick" function, a tab specific JavaScript function at 285 is called within the pop-up window's HTML file. This function sets the display style attribute for the DHTML objects that define the settings for all the non-selected tabs to the display style attribute of "none". The DHTML objects that define the GIF image of the non-selected tab file representations are also set to the display style attribute of "none". The display style attribute for the DHTML objects that define the settings of the currently selected tab and the GIF image that depicts the selected tab file representation is set to the display style attribute of "". If there is to a change of the focus of the selected field within the now to be visible tab specific choices, the focus attribute for that object is executed. Screen shot FIG. 37 shows a visualization of a tabbed pop-up window, and screen shot FIG. 63 shows a collage of four views of a tabbed pop-up window with four tabs. Notice that each state of the tabbed pop-up window has a different tab file representation, showing the selected tab as being in the forefront.
The interface technology of the invention, in addition to its utilization as part of a web-based web site generation tool, can be used to provide a general purpose interface for all web-based applications that want a MS Windows compliant interface.
A process for updating the internal database of the build engine 352 is shown schematically in FIG. 8. The database is compact and efficient in order to meet the performance requirements for the run time process. The database handles a wide selection of data objects, including multi media objects such as colors, fonts, images, sound clips, URLs, threads, and video. The database supports a multi level animation, transformation, and time line model (discussed in greater detail below). The database complies with the differing rules imposed by the various popular browser security managers.
The process begins by determining the type of data to be updated at 60. Data that defines generic web site settings (See FIG. 21a), screen resolution values (See FIG. 21a and FIG. 24), and the web page high watermark setting (See FIG. 24) can be stored in a header record as boolean and integer variables and URL and color objects at 62 and 63. Data that defines web page, paragraph, text button, and image style and text button, image and paragraph high watermark settings can be stored in one-dimensional arrays as boolean, integer and string variables and URL, font, image or thread objects at 61 and 64. The URL, color, font, image and thread objects can also be created as required at 64.
Data that defines text button, image, paragraph, or other parent objects and paragraph line high watermark settings can be stored in two-dimensional arrays (by web page and by object number) as boolean, integer, string, floating point variables and URLs at 65 and 66. Again, the URL, color, font, image, audio clip, video clip, text area and thread objects can also be created as required at 66. Data that defines a paragraph line and paragraph line segment high watermarks can be stored in three-dimensional arrays (by web page, by paragraph number, and by line number) as Boolean, integer or string variables at 67 and 68. Again, the URL, color or font objects can be created as required at 68. Data that defines a paragraph line segment can be stored into four-dimensional arrays (by web page, by paragraph number, by line number and by line number segment) as Boolean, integer or string variables or URL, color and font objects at 67 and 68. As a data field is added, changed or deleted, a determination is made at 69 on whether a value for a given high watermark needs to be changed. If so, it is updated. As a specific method in the build engine is called, a determination is made at 70 on whether a feature flag needs to be set. For example, if a particular JAVA method is called, which requires an instance of a certain JAVA Class to be executed by the run time engine, then that JAVA Class is flagged, as well as any supporting methods, variables and/or object definitions. The use of these flags is described in greater detail below in association with FIG. 25 and FIG. 27 to create a compact and efficient customized run time environment.
In one implementation, the header record, the style record, the web page record, and the object records, are carefully defined in a specific order, written in that order, and explicitly cast by object type when read by the run time engine. Exception handling can be implemented to recover from any errors. This helps assure that data integrity is maintained throughout the build and run time processes.
FIG. 9 details the polling process (16 of FIG. 3). The polling technology is essential for creating the necessary two-way real time communication between the JavaScript/HTML interface and the JAVA build engine. Since there is no particular difficulty for JavaScript to be able to call and pass values directly to JAVA methods, the technological challenge is to find a reasonable technique to enable JAVA to communicate back to JavaScript. The polling technology is generic, and workable across all the current browsers. The polling technology is flexible, as there are no real constraints as to what data could be communicated from the build engine to the interface, and this communication can occur at any time. The polling technology is reasonably efficient, so that the performance of the build process is not significantly affected.
In one implementation, two different techniques were utilized to implement this capability. The first was to place the build engine inside a JAVA wrapper. The JAVA wrapper accepts direct communication from JavaScript function calls, interrogates a particular JAVA build engine method, and returns that method's return value back to the calling JavaScript function. The second technique was more unconventional. A polling loop is defined in the panel's (panel 400) JavaScript that creates a near continuous, at least from a human perception point of view, dynamic real time link, in order to monitor events occurring inside the build engine. The result is a real time retrieval (from an ergonomic perception point of view) of necessary data and status settings from the build engine back to the interface.
Upon the loading of the panel HTML file, a JavaScript function at 71 (the poller) is immediately called which initiates a polling loop. In one implementation, the polling loop is set at a poll rate of once every 100 milliseconds or less. The polling routine, operating through the JAVA wrapper, calls the build engine in order to read the current horizontal and vertical coordinates of the mouse cursor, and displays them in the panel's status fields (FIG. 37 at 450). The polling routine also polls the build engine in order to detect whether the mouse has moved over a valid object or, by inference, whether a mouse single click, or double click event has occurred. The poller is also constantly requesting the JAVA wrapper to return the status of an error flag in order to inform the user, if necessary, of an unrecoverable error condition, and the reason for it. (See FIG. 10). The poller then calls a panel JavaScript function that, in turn, calls the build engine to reset the flag. The poller constantly requests that the JAVA Wrapper return the status of whether the mouse cursor is over a valid object, and, if so, that object's number, type, height and width. The poller also constantly requests the JAVA wrapper to return the status of whether an object is selected, and, if so, the type and number of that selected object, as well as the objects height, width, and 3D frame state (and the point size of the object's current font if the object is a text button or paragraph object). In addition, if the object is a paragraph, the poller constantly requests the JAVA wrapper to return a flag if a double click or drag mouse event has occurred.
At 72 the polling routine detects a mouse event based on analyzing the return values received. The poller can infer that the mouse has either moved off or moved on to a valid object at 73 if the mouse over object state has changed or the mouse over object number has changed. If so, the poller updates the relevant interface objects of the panel as appropriate and displays them as necessary, and, depending upon whether the object is a text button object, a paragraph, image object, etc., at 75, begins polling their unique values.
The poller can infer that a single click mouse event has occurred at 74 if the selection state has changed, or the selected object changed. The poller updates the menu bar (FIG. 37 at 410) as appropriate, making the appropriate menu commands either active or inactive. The poller also sets the necessary status variables, and, depending upon whether the newly selected object is a text button object, a text object, image object, etc., at 74, begins polling their unique values. The poller also activates the appropriate menu choice objects inside the "Edit" menu, the "Text" menu, the "Button" menu, the "Image" menu, and the "Interactions" menu objects (FIG. 37 at 420 and 430), depending upon whether an web page object is selected or not, which type of web page object is selected, or, if the selected web page object is a text object, whether text is marked through a drag or double click event. In a similar manner, the poller also sets the values for the interactive field objects (FIG. 37 at 460) and the interactive drop-down list objects (FIG. 37 at 470). More specifically, JavaScript can poll the web page object number. The value of the web page object number can be used to initialize pop-up windows with that object's web page current values, either from the panel's database or, if necessary, by interrogating the build engine's database.
The poller can infer that a double click or mouse drag operation has occurred if the flag indicating a double click or mouse drag operation is detected at 75. The poller calls a panel JavaScript function that, in turn, calls the build engine to reset the flag. The poller then calls a panel JavaScript function to display the appropriate panel menu choices. For example, if the double click or mouse drag event occurs within a text object, then the "Text Style and "Hot Link" menu choice objects become active under the panel's "Text" menu object.
Depending on the object type (76), the polling technology performs various functions. If the object is a text object at 77, the values for the paragraph style, point size, object height and width, text color, and the 3D frame status are polled and displayed. The panel's menu objects and the menu choice objects within that are active for a text object are set to the active state, and the non-text menu choice objects are set to the inactive state, which visually means they are unavailable and are "grayed out". In addition, polling can be initiated for the creation of a hot link. If the object is a text button object at 78, the values for the text button style, point size, object height, width, text color, animation state, and 3D frame status are polled and displayed. The menu choice objects inside the panel's menu objects that are active for a text button object are set to the active state, and the non-text button menu choice objects are set to the inactive state, which visually means they are unavailable and are "grayed out". The value of the text button object string is also polled and saved in the panel's database for use when initializing relevant pop-up windows. If the object is an image object at 79, the values for the image style, object height, width, frame color, animation state, and 3D frame status are polled and displayed. Again, the menu choice objects inside the panel's menu objects that are active for a image object are set to the active state and the non-text button menu choice objects are set to the inactive state. In addition, the results of any relevant direct object manipulation are polled and displayed.
FIG. 10 describes a two level error correction technology (17 of FIG. 3) employed by the build process. Initial error checking occurs during the interactions between the user and the interface with the JavaScript error checking code at 80. Any file name, selected by the user through the file selection window or typed in a file pathname (See FIG. 6 at 49) is checked by the panel's JavaScript to assure that it has the correct file type suffix (gif, jpg, au, etc.) at 81.
The panel's JavaScript Code performs range checking at 82 to prevent user error or to prevent the breaking of any internal limits imposed by the build engine. These can include: going to a non-existent web page; exceeding any limit with the dual spin control (i.e. attempting to increment or decrement a point size outside of the legal range, or trying to illegally decrement a value to zero or a minus number; typing in a numeric value that is outside a legal range; and, implicitly creating an object that exceeds a limit imposed by the build engine).
The panel's JavaScript code also checks the file pathname to make sure it contains a valid address, and makes necessary additions or conversions, if necessary, at 83. For example, if the user selected a file from the local disk, the correct URL protocol is appended to the file name in order to make it a valid string representation of a URL address. Any illegal characters for a pathname or a null file pathname entry are also caught at 83. In addition to file pathname validity checking there are other validity checking functions that can be employed by the JavaScript at 83. They include the attempt by the user to enter a non-numeric character into a numeric field, or leaving an essential fill-in field empty.
The panel's JavaScript then passes these values to the build engine though the arguments of a JAVA method function call at 84. The build engine can utilize the extensive exception handling capability of JAVA at 85 (or that of any other full featured programming language used) to attempt to recover from any processing error. If recovery is not possible, the build engine sets an error flag, utilizing the polling technology (See FIG. 9 at 71). The poller, upon detecting this flag, informs the user, for example, through an alert JavaScript pop-up message, what non-recoverable error has occurred, from which operation, and what actions, if any, the user should take. For example, if the user had selected a corrupted image file, the exception handling technology can inform the user of this fact so that user corrective action can resolve this very common problem. In one implementation, error handling and exception recovery support is provided for a malformed URL, an input or output error, a security manager violation, and a null pointer error.
FIG. 11 shows a process for text entry and text processing (18 of FIG. 3). The process begins when the panel's JavaScript detects the user selecting either "Button" or "Text" icon objects from the panel's tool bar or from their equvalent menu choices under the "Button" or "Text" menus, and calls the appropriate JavaScript function at 86. The JavaScript function, after performing a range check to assure that no internal limits of the build engine are being broken, updates its database, and sets the necessary status variables. The panel's JavaScript then calls the appropriate build engine method, passing the necessary arguments, including the current board number, the internal number to be assigned to the object, the object type, and the current text button or paragraph style at 87. The build engine then updates its internal database and sets the necessary status variables. The build engine also changes the mouse cursor shape to that of a text entry symbol. In one implementation, the mouse cursor is shaped like a crosshair, and can be moved onto the web page (the build frame 402) at an arbitrary location.
The build engine detects a mouse click event through its "mouseDown" method at 88. This method reports to the build engine the exact horizontal and vertical coordinates of the crosshair mouse cursor at the moment the mouse button is pressed. The build engine places these values into its internal database. The polling process is also supported, as discussed in FIG. 9, by placing the necessary return values in the appropriate poll enabled methods.
The build engine-creates a dynamically resizable frame utilizing JAVA's "Text Area" object class, whose coordinates and size coincide with that of the draw system for the object as defined below. Other full-featured programming languages, if used by the invention, also possess similar object types. The text area is immediately overdrawn by the draw system's background paint routine. The build engine, utilizing the font metrics as defined by the selected text button or paragraph style, and utilizing the crosshair cursor's coordinates, calls the draw system. The draw system paints the background and then paints an insertion point and a selection rectangle, in the appropriate colors, and with the appropriate height and width, into the appropriate web page location at 89. If the text button or paragraph style has a 3D frame selected, this intelligent ornamental object would also be drawn, in the appropriate color, dimensions, and thickness. Screen shot FIG. 41 shows a visualization of this process. The text insert point is in black, surrounded by a red selection rectangle, and surrounded by a blue 3D frame, as defined by the selected style. The text editor is then initialized by setting the necessary status variables.
The build engine waits until a keyboard keystroke is detected. The scan code is interpreted, and if it is a text entry key, the text editor's methods are called at 90. The text editor processes the key event at 91. The build engine employs frame (Text Area) processing methods and draw methods to implement the text entry and text processing functions. As a keyboard key for a text character is pressed, the build engine passes this value to the editor's text entry method, which updates both the text area's frame definition, and the draw system's database. The width of the text area is dynamically resized as necessary. If the object was a paragraph, a check is made on whether a reformat event should occur, based on the paragraph style's definition and the width of the current line's text string. If so, the appropriate text editor reformat method is called, which may cause the text area's vertical dimension to also be resized. A high watermark variable may also be set, for optimization purposes. After the final state of the text area is determined for the text entry keyboard event, the internal database for the text area, and for the paragraph or text button object, are updated. The draw system is called, and the results of the text entry event are drawn on the web page at 94.
In one implementation, the build engine also supports the usual text processing functions found in MS Windows or Macintosh based Word Processors or Desktop Publishers at 92 and 93. For example, if the user single clicks the mouse when over an unselected paragraph or text button object, that object is selected, a selection rectangle is drawn, the mouse cursor shape is changed to a crosshair, and the poller reports the necessary information to the panel's JavaScript. If a mouse click occurs over a selected paragraph or text button object, the editor's "Set Text Insertion Point" method is called. Based on the coordinates of the mouse cursor, and based on a calculation by the build engine as to the nearest line, and the nearest character on that line, the text insertion point can be drawn appropriately, and the necessary status variables are updated. Text entry is then processed as discussed at 91.
If a double click or mouse drag mouse event is detected over a paragraph, an appropriate "text string selection" method is called (See FIG. 6). Based on the coordinates of the mouse cursor, and based on a calculation by the build engine as to what text string should be selected, the internal database in updated, appropriate status variables are set, and the draw system is called for marking the text string at 94. The polling technology is activated as discussed in FIG. 9. The build engine's reformat methods for paragraphs can utilize a "Clean Text Stream" model for calculating line breaks and for updating four-dimensional variables utilized by the draw system in order to draw each paragraph, each paragraph line, and each paragraph line segment in the correct location, with the correct font type, font style, font size, font effect, and background and text string color. Font style refers to a font format such as Normal, Bold, Italic, or Bold Italic. Font effect refers to style overrides such as Underline, Double Underline, Small Caps, Cross Out, Superscript, Subscript, etc. The "Clean Text Stream Model" implemented by the build engine maintains multi-dimensional array pointers and records for every paragraph line and line segment external to the text string defined within the text area. Three-dimensional and four-dimensional variables are updated after each text entry or text editing and processing event in order to assure that the pointers into the paragraph text stream, defined in the text area, are current. The three-dimensional variables that the build engine has implemented can include soft and hard line end pointers for each paragraph line. Their values can be the absolute character positions within the text area text string for that line end. Hard line breaks can be created by the user pressing the enter key. Soft line breaks can be created by a reformat method based on a calculation defined below.
The four-dimensional variables can be absolute pointers into the text area text string for the beginning and end of every style override, associated with each paragraph line segment. These style overrides can include hot links, font type, font style, font size, numerous font effects, and text and background colors. For each style override there is an associated style override record that maintains all the font and color settings for that paragraph line segment. Also positional and size data such as start and end pointers into the paragraph text stream, a left offset relative to the paragraph's left origin, a top offset relative to the paragraph's top origin, and the line height. The style override record is created when the build engine detects a mouse drag or mouse double click event within a selected paragraph. When the mouse button is initially pressed, the current paragraph line and current word on that line are calculated in a manner identical to that for calculating the location of the text insertion point on a mouse click operation. The entire word becomes one anchor for the paragraph line segment, while the word defined by the mouse coordinates when the mouse button is released becomes the other anchor. Up to two other paragraph line segments can be implicitly created by the word oriented selection method. If there is text to the left of the first anchor word, and that paragraph line had not previously had a style override defined in it, the text string from the beginning of the paragraph line to the first anchor point has a style override record created for it. The values are set to that of the underlying paragraph.
If style overrides had already been created on that paragraph line, and the anchor word is inside one of them, then that style override's end pointer is adjusted to the start of the anchor word. All other style overrides, if any, to the right of the anchor word are deleted, as overlapping style overrides are not permitted. In a similar manner, the text string, if any, to the right of the last anchor point, up to the line or paragraph end, can also be defined as a style override. If a mouse click occurs before a "text style" operation, then these pointers will be reset. If the panel's JavaScript detects a user selection of "text style" from the "Text" menu, the appropriate pop-up window is drawn and its values initialized from the JavaScript database. Upon detecting a user completion event (i.e., the depressing of the enter key), the panel's JavaScript database is updated and a call is made to an appropriate build engine method, with the necessary data and status information passed as function call arguments. The build engine updates its internal database and calls the reformat method if necessary. The draw system utilizes these four-dimensional variables in order to paint the paragraph line segment style override.
The calculation for the creation or updating of a soft line break begins with the maximum paragraph width, which is set at a percentage of the browser screen width. This percentage is converted to an absolute pixel number based on the web designer's screen resolution. When any text entry or text editing and processing event occurs, a build engine method is called which calculates the width, in pixels, for the current paragraph line, based on the character string in the text area that exists between the previous line end pointer and the current line end pointer. The font definition(s) that are related to this character string are applied, and a string width is calculated. If the string width exceeds that of the maximum paragraph width, an "OverFlow" reformat method is called. The overflow reformat method calls a method to determine the settings for the last word on that line, and that word overflows to the following paragraph line. All pointers for the current line, and subsequent lines are updated as necessary, as are all pointers and records to paragraph line segments. If the string width is less than that of the maximum paragraph width, and the text processing operation was not text entry, then an "UnderFlow" Reformat method is called. The underflow reformat method calls a method to determine the width, in pixels, for the first word on the next line. If that word will fit on the current line it is placed there. As before, all pointers for the current line, and subsequent lines are updated as necessary, as are all pointers and records to paragraph line segments. The word oriented selection technique, and the reformat, database, and draw technologies that support it, greatly simplify the text editor and produce a run time engine that is smaller, faster and more reliable.
FIG. 12 shows the operation of the image processing technology utilized by the build engine (19 at FIG. 3). The process begins when the panel's JavaScript detects the user selecting the "Image" icon from the panel's tool bar or the comparable menu choice under the "hnage" menu. The appropriate JavaScript function is called at 95, which draws the define image pop-up window. The user then selects an image from the file selection window with the browser, types in the image pathname for the image file on the local disk, or types in the URL for the image that exists on a server. The user could also define a 3D frame for the selected image at this time. Screen shot FIG. 49 shows a visualization of a collage for the define image pop-up window and the user's selection choices under each tab setting. The user can complete the selection process by either pressing the Enter Key or clicking on the "Create Image" icbn in the pop-up window. If the Enter Key is pressed, the pop-up window's JavaScript Code utilizes the onKeyDown function, or if a mouse click, the onClick function, as described in FIG. 7, to recognize the completion event. An appropriate error checking JavaScript function is called, which performs a file name error check, a filename validity check, and a range check to assure that no internal limits of the build engine are being broken. If the error checking tests are successful another JavaScript function is called to update the panel's database, and set the necessary status variables.
The panel's JavaScript then calls the appropriate build engine method, passing the necessary arguments, including the current internal web page number, the internal number to be assigned to the image object, the object type, and the current image style at 96. The build engine then updates its internal database and sets the necessary status variables. It also changes the mouse cursor shape to that of an "Image Create" symbol. In one implementation, the mouse cursor is shaped like an arrow. The build engine detects a mouse click event through its "mouseDQwn" Method at 97. This method reports to the build engine the exact horizontal and vertical coordinates of the arrow mouse cursor at the time the mouse button was pressed, and places these values into its internal database. The polling process is also handled, as discussed in FIG. 9. The build engine then asserts the necessary security permission for reading from the local disk, if necessary, and attempts to create the necessary image object at the current mouse coordinates at 98, while checking for any exception conditions as described in FIG. 10. If no unrecoverable exceptions are reported, the internal database is updated and the draw system is called.
The image processing technology supports direct web page image object interactions at 99, utilizing the communication technology described in FIG. 6. The build engine first processes the mouse event as described in FIG. 7, and places the appropriate values into a poll enabled JAVA method as described in FIG. 9. There are two types of direct web page image object interactions. s The first occurs by simply selecting the image object with a single mouse click. A red selection rectangle is drawn around the image, as are eight attachment points. When the user has pressed the mouse cursor, the mouse cursor's shape changes to that of an anchor, which is a symbol that can be used when dragging or moving an object. The mouse's location will jump to the origin for the image. In an alternative implementation, the anchor can be defined by the mouse location at the time of the mouse drag operation. In either case, while the mouse is being dragged, the build engine updates its internal database. The build engine also updates its poll-enabled methods for communication with the interface's polling technology at 100. The JavaScript poller reads these values, updates the panel JavaScript database, and updates the panel's interface objects. In a similar way, placing the mouse cursor over an attachment point and dragging will result in an image resizing operation. Screen shots FIG. 50 through FIG. 52 show a visualization of an image dragging operation. Screen shot FIG. 50 shows the cursor over an unselected image. Screen shot FIG. 51 shows the screen state after the left mouse button has been pressed. Notice that the image is now selected and the cursor shape has changed to the drag state. Screen shot FIG. 52 shows the screen state after the mouse has been dragged to the northwest. Notice that the image stayed selected and moved with the mouse. Screen shots FIG. 53 and FIG. 54 show a visualization of an image resizing operation for a normal image. Notice that all eight-attachment points are drawn and active for the selected image. Screen shot FIG. 53 shows the cursor over the upper left attachment point. Notice that the cursor shape has changed to a northwest to southeast resize cursor shape. Screen shot FIG. 54 shows the result after the left mouse button has been pressed over the upper left attachment point and dragged to the northwest. Notice that the image's upper left corner is still under the cursor, the image has resized, and the cursor shape remained unchanged. For image resizing operations with the mouse over and mouse down objects, only the east, southeast, and south attachment points are drawn and active.
The second type of direct web page image object interaction occurs when the panel's JavaScript code detects that the user has selected an image object interaction feature from the panel's "Image" menu. The appropriate JavaScript function is called, which sets the necessary status variables, and then calls the appropriate JAVA method, passing the necessary values as arguments. The JAVA method then sets its necessary status variables, changes the mouse cursor shape as appropriate, depending upon the type of direct image operation, and awaits a direct mouse operation on the image object. Image rotation is an example of this type of direct image interaction. In one implementation, direct image object rotation is realized by utilizing the image rotation technology described in association with FIG. 33 below. Screen shots FIG. 55 and FIG. 56 show a visualization of an image rotation for a normal image. Screen shot FIG. 55 shows the user selecting the rotate command from the "Image" menu. Immediately the cursor's shape changes to the rotate (a dual left/right arrow) cursor, and the selected image's attachment points disappear. Placing the cursor on the image and dragging will cause the image to rotate on an east/west and/or north south axis. Screen shot FIG. 56 shows the result after the mouse was dragged on an east/west plane.
Image object interactions are invoked by selecting from the JavaScript panel, selecting from a JavaScript pop-up window, and by selecting from a JAVA window object at 101, as described in FIG. 6. The initial values in the pop-up window are set from JavaScript's database. After any user interaction, JavaScript's database is updated and the appropriate method in the build engine is called with the necessary settings. The build engine, after updating its internal database, calls the appropriate image processing method. The image processing routine then calls the required image filter(s), which then perform the necessary processing on the image bitmap at 102.
An image filter is a body of code, usually consisting of one or more digital image processing algorithms, which operate on an image bitmap, and create a transformed image bitmap. An image observer can be invoked by the image filter, which then reports when the image bitmap processing has been completed. An image observer is a independent process that monitor's a particular image processing event, such as the execution of an image filter or the reading in of an image file, and reports the status of that process when queried. When the image observer reports a successful completion, the image filter can call the build engine's draw system to display the transformed image bitmap. This interaction between the build engine's image processing method, the image filter(s), the image observer, and the draw system can occur many times, depending upon the image processing operation chosen. Image animations and image transformations, which are technologies that rely heavily on image filters, and the image observer are discussed in greater detail below in association with FIG. 16 and FIG. 17.
FIG. 13 shows a process for implementing text button, image and paragraph style settings (20 of FIG. 3). The initial values for all the settings inside a parent pop-up window and associated child pop-up windows, for a particular style, can be set from the JavaScript database at 103. The settings can include: image object styles, text button object styles and paragraph object styles.
The following settings can be initialized and changed for image object styles. The following settings are initialized for all image object states (Normal, mouse Over, mouse Down) and can be changed:
(1) resize factor.
(2) rotation factor.
(3) main animation type, speed, number of animation steps (resolution) and number of cycles.
(4) image processing factors. (brightness, contrast, etc.)
(5) 3d effects and their color values.
(6) web page centering attribute.
(7) web page scaling attribute.
b) The following actions are initialized and can be changed.
(1) sound effects and audio channels.
(2) video files and video channels
(3) text button and image pop ups and their attributes (See 1.a above and 2.a below.)
(4) click events.
c) The following transformation settings are initialized and can be changed.
(1) the initial delay
(2) up to three transformations can be defined with the following settings:
(a) which image states should the transformation be from and into.
(b) the speed of the transformation.
(c) any delay before the next transformation.
(3) whether the transformation(s) should occur simultaneously with the enter and exit time line animation or after the enter and before the exit animations.
d) The following time line settings are initialized and can be changed.
(1) the initial delay before the image object's appearance.
(2) the enter animation type, speed, and animation resolution.
(3) the delay after the enter animation and the main animation.
(4) the exit animation type, speed, and animation resolution.
(5) the initial delay, after the entrance of the parent object, before the child text button and image object's appearance(s).
(6) the child object(s) enter animation type, speed, and animation resolution.
(7) the delay after the child object(s) enter animation.
(8) the child object(s) exit animation type, speed, and animation resolution. The following settings can be initialized and changed for text button object styles.
e) The following attributes are initialized for all text button object states (normal, mouse over, mouse down) and can be changed:
(1) all font specifications.
(2) vertical state.
(3) all |
