a description of the details and function of the present invention is provided below . the source code listed in appendix a , written in java , details the implementation of a preferred embodiment of the invention . the patentee has no objection to the reproduction of the source code or other information for the purpose of obtaining and maintaining a valid patent . however , the patentee otherwise reserves all copyright interests . the invention is embodied as both a process to be executed on a computer , typically a web server , and a computer program product providing computer readable program code means for executing the various steps of the process . the computer readable program code is embodied on a computer readable medium . the computer readable medium may be either fixed , such as a mass storage device or a memory , or it may be removable , such as a cd or a diskette . the invention is implemented through the use of conventional computer programming techniques well known to those skilled in the art . while the source code provided in the attached appendix is written in java , other programming languages would also be suitable for programming the invention . while the invention is preferably programmed in an object - oriented language such as java or c ++, other embodiments , consistent with the spirit and scope of the invention , programmed in procedural languages or scripted languages , are also possible . referring now to fig1 , the invention provides a process for optimizing generation of a computer readable document incorporating static and dynamic content 10 , particularly web pages being served up to a client in response to a request from a user . as previously mentioned , one of the most common ways of generating web pages having dynamic content is to start with a page template . typically , the page template is a file of html code containing placeholders where the dynamic content is to be inserted . the placeholders usually consist of tokens . for example “@ username @” might be typically used as a placeholder for a user &# 39 ; s name . when the template is created , or after it is edited , it is saved to disk , typically on a web server . thereafter , the html file is read from the disk and parsed to locate the “ live ” or dynamic sections , which have been set off or reserved by the tokens . the invention provides a process in which the html file need be read from disk and parsed only once , unlike prior art methods , which require that the file be read and parsed every time a client requests the page . in the current embodiment of the invention , the html file is read from the disk 11 by means of a helper software object tasked with various utility file operations , such as reading in files , getting file lists and so on . reading pages of “ static ” content is performed by a “ getcontent ( )” method embodied in the helper object . the getcontent ( 0 method of the helper object retrieves the raw html file and stores the raw content to the cache as a string . more detailed descriptions of the operation of the helper object and the “ getcontent ( )” method are to be found by referring to the documentation provided in the enclosed appendix . when parsing the html file for caching and token replacement purposes , the goal is to separate the html file into its component static pieces , dynamic pieces , and replaceable token pieces . a common term of art for this process is “ freeze - drying ” 12 . the invention provides a contentcomposer class that is the sole parser and manager of this freeze - dried content . each html file has a separate instance of the contentcomposer object associated with it . in keeping with conventional methods of object - oriented programming , in which an object includes both instructions and the associated data , the contentcomposer object for a particular page includes the implementation logic and the raw content string . when a file is loaded , the helper object checks to see if a contentcomposer object exists for the file . if the file has no associated contentcomposer object , the helper object creates one 20 . a global hashmap , held in the cache , provides storage for contentcomposer objects . thus , following creation of the contentcomposer , the new contentcompser object is stored to the global hashmap . in this way , the deconstructed file data is effectively cached , so that it may be used on subsequent invocations 21 . after being cached , contentcomposer parses the html file by “ decomposing ” the raw code string , separating it into its various components 22 . components are one of three types : blocks of immutable content containing no tokens ; lines of immutable content that surround tokens ; and token replacement values . according to a preferred embodiment of the invention , a token comprises a string that starts and ends with the “@” characters and contains no embedded white space , newline characters , colons , semi - colons , or commas . however , the delimiting characters are a mere matter of choice , dictated in this case by the conventional manner of creating tokenized html code . in some cases , only the token is replaced , in other cases , the entire line containing the token is replaced . for example , the method allows calling processes to replace the whole line of text that the token was on , which is a frequent operation for callers replacing & lt ; li & gt ; or & lt ; select & gt ; items . as previously described , the helper object provides a raw code string to the contentcomposer for parsing . a setcontents ( ) method within the contentcomposer provides most of the parsing logic for the invention . the setcontents ( ) method parses the raw content string to locate delimiting characters . upon locating a delimiting character , the parsing engine evaluates the string for the presence of the previously indicated illegal characters — white space , newline characters , colons , semi - colons , or commas . the presence of any illegal characters indicates that the delimiting character is not associated with a valid token . “@ foo bar @” or “ keith @ iamaze . com ” are examples of such invalid strings . as the various page components are identified , they are stored to one of several data objects that are also associated with the contentcomposer . after the page components are identified , the page is decomposed by saving the separate components to a plurality of data structures 23 . these data structures are described in greater detail below . it should be noted that the process of separating the page into components and storing them in the data structures constitutes the process commonly known as “ freeze - drying .” while , for the purpose of description , the data and the data structures are described separately from the logic and instructions , they are , in fact , all associated within a single contentcomposer object , which is held in the cache . thus , as with the raw code string , the data structures containing the page components are effectively cached , eliminating the necessity of any further disk accesses when the html file is composed . after the page components are cached , calling processes can ask the contentcomposer to perform token replacement , which it can do very fast : in 0 - 1 time , the tokens are stored in a hashmap as described below . the final part of sxcontentcomposer &# 39 ; s lifecycle is when the caller asks the contentcomposer to “ compose ( )” itself , thus creating a page for download to a client 13 . the compose ( ) method itself provides additional important performance gains . rather than recomposing the html into a string , and passing the string to the calling process , extremely wasteful of memory and processor time , the contentcomposer walks through the data structures and writes the data to an output stream as it is walking 14 . this implementation holds three primary data structures . it is necessary to hold this parsed data in three disparate , but linked , data structures because the data must be accessed from a number of different “ angles ”, and for a number of different purposes . the composer will need access to all the original static text , plus some way to gather the token replacement values . the caller will need to replace token values ( by specifying the token name ), or the whole line the token is appears on . the caller may also want to inspect the line a token appears on . the first is an array of immutable content broken up into “ chunks ” 30 . each chunk is either a text block with no “@ foo @” tokens , or it is an integer object pointing to the index of a token replacement object , ( sxtokenline ) which will supply the values ( string ) for that chunk . the second data structure is also an array of immutable content : an array of the token - replacement - objects mentioned above 31 , and pointed to by the chunks array . these token - replacement - objects are of type token line and they hold the static text that immediately precedes and follows a token . they also hold the raw token name itself ( e . g . “@ foobar @”) as well as a pointer to an object stored within the third data structure , a structure that holds the replacement line or replacement value associated with this token . this final object is of type token . while the names assigned to the various page component types in the current embodiment are descriptive of their content , they are primarily a matter of choice . the third data structure is a hashmap with all the tokens from the raw content as keys and all the replacement values set by the calling process as the values 32 . these replacement values are of type token object , which can hold a replacement line or a replacement value for a token . note that the immutable text chunks never change throughout the life of this object , while the values stored in the tokens and replacement values hashmap are likely to change every time content is created , since tokens and replacement values represent the dynamic portion of the content . furthermore , to reduce the overhead of future writes to streams , and to reduce the excessive creation of string objects , the static data in both the immutable text chunks array as well as the immutable token lines array is stored as byte ( ), rather than string . the compose ( ) method of the contentcomposer writes each text chunk and token replacement value to an output stream in sequential order , creating a single , coherent , token - replaced text stream . as the contentcomposer walks the immutable text chunks array 40 , if it encounters an array entry that is a token rather than a chunk of text , instead of concatenating the actual token , it concatenates the value for the token found in the tokens and replacement values hashmap 41 . the specific process and data structures used by the contentcomposer are described in greater detail in the example provided below . & lt ; html & gt ; & lt ; title & gt ; iamaze presentation tool & lt ;/ title & gt ; & lt ; h1 & gt ; welcome to iamaze , @ username @! & lt ;/ h1 & gt ; & lt ; br & gt ; & lt ; br & gt ; would you like to work on the presentation you last worked on , named @ lastpresentation @? & lt ; br & gt ; if so , click here . & lt ;/ html & gt ; immutabletextchunksarray [ 0 ] = “& lt ; html & gt ; & lt ; title & gt ; iamaze presentation tool & lt ;/ title & gt ;” immutabletextchunksarray [ 1 ] = “ new integer ( 0 )” ( use to look up , at index = 0 , this token &# 39 ; s pre - & amp ; post - sxtokenline line text objects in the “ immutabletokenlines ” array .) immutabletextchunksarray [ 2 ] = “! & lt ;/ h1 & gt ; & lt ; br & gt ; & lt ; br & gt ;” immutabletextchunksarray [ 3 ] = “ new integer ( 1 )” ( index into “ immutabletokenllines ” array , above and below ) immutabletextchunksarray [ 4 ] = “? & lt ; br & gt ; if so , click - here . & lt ;/ html & gt ;” immutabletokenlinesarray [ 0 ] = { sxtokenline { prefix = “& lt ; hi & gt ; welcome to iamaze , ” suffix =”! & lt ;/ h1 & gt ;”, pointer to sxtoken object in the tokensandreplacementvalues } immutabletokenlinesarray [ 1 ] = { sxtokenline { prefix =” would you like to work on the presentation you last worked on , named : “, suffix =””, pointer to sxtoken object in the tokensandreplacementvalues } thus , the data structures for the example page appear as shown above immediately after the parsing or “ freeze - dry ” process . after being supplied values by calling process , for example , in response to a request from a user , two separate methods are called to replace the tokens with the new content : the first call replaces the entire line containing the token . the second call replaces only the token . the immutable text chunks and the immutable token lines arrays remain the same , since they contain immutable data . a call to sxcontentcomposer &# 39 ; s compose ( ) or tostring ( ) methods generates the following : would you like to work on the presentation you last worked on , named the tostring ( ) method outputs a string to the output stream in a fashion similar to the compose ( ) method . more detailed description of the tostring ( ) method as well as the replacelinecontainingtoken ( ), and replacetoken ( ) methods is to be found below . although the invention has been described herein with reference to certain preferred embodiments , one skilled in the art will readily appreciate that other applications may be substituted without departing from the spirit and scope of the present invention . accordingly , the invention should only be limited by the claims included below .