Re: Question about replacing words
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 19695
interpreted = N
texte = >>Anyways, lots of other software does it: Panorama, FileMaker, BBEdit, >>Tex-Edit, etc. etc. > >No, they don't. They may change a *single* word at a time, but that's >significantly different from what you're asking. No it's not. They all change single strings of text, not just single words. And it's no big deal to change one match string at a time, then to run the process thru another cycle to change the second match string, then again to change the third, and so on until they have all been changed.I'm sure you know that performing this task by using a database of match strings would very much like using a founditems loop to perform a database field value replacement, as in this example:[search] [founditems] [replace db=xxx.db&eqskudata=[sku]]from=[to][/replace] [/founditems] [/search]This example doesn't replace everything all at once, it sequentially replaces the from field with the [to] value in the first matching record, then in the second matching record, then in the third, etc. So why not use a similar technique for multiple match string replacements? there's no problem cycling thru any number of match strings. Granted, the more match strings there are, the slower the process will occur. But right now I could care less how slow it is, because right now it's not even possible! Maybe after it's possible we can start worrying about whether or not it's fast enough ...All I'm asking is to replace *one* match string at a time ... then when that ONE match string has been properly replaced in *each* position where it occur in the text, only then will webcat move onto the NEXT match string and replace ALL the occurrences of that SECOND second match string, one at a time, until they have all been replaced ... then on to the third match string, then on to the fourth, and so on ...This would work just fine ... but ...The method that's used to perform these individual 'find and replace' events in each cycle is the major issue here ... and this is something that needs to be done properly ...And that means NOT parsing from the beginning again each time a 'find and replace' event is performed, but instead, the text parsing for each SUBSEQUENT replacement must begin at the position immediately FOLLOWING the LAST replacement.This is the key to making this technique work properly, and I don't see the problem in implementing this technique ... is there one?Webcat should begin the process by parsing the original text until it 'finds and replaces' the FIRST occurrence of the FIRST match string in the database. Then it should perform its 'find and replace' event on that match string. Then it should simply continue parsing from that point (not from the beginning) until it finds the NEXT occurrence of the FIRST match string -- then it should replace that match string. Then it should continue doing the sate thing until it can no longer find the FIRST match string, which will definitely occur at the end of the text.Then when it gets to the end of the text, it would 'load' the SECOND match string and start over -- from the beginning this time -- performing the very same cycle of 'find and replace' events it just performed with the FIRST match string -- only this time it will do it with the SECOND match string.Then it would continue to perform this sequence of 'find and replace' events for each ADDITIONAL match string it finds in the database. And when it has eventually finished performing this same cycle with each of the remaining match strings in the database, it would output the results. This technique would result in the replacement of ALL the occurrences of ALL the match strings defined in the database -- without ANY chance of an infinite loop occurring. Because the only way an infinite loop can occur is if the parsing starts over from the beginning after every 'find and replace' event INSTEAD of after every match string 'cycle'.In other words, this proposed method of parsing, finding and replacing would do *exactly* what we want and need, without any possibility for error or crash (unless it requires more memory than webcat has made available to the thread performing this task -- but that's another issue entirely).As long as the 'find and replace' events do not cause the parsing to begin again from the beginning, the *deadly endless loop* problem I described previously cannot occur ...Are there other problems to be addressed in the design of this potential new webcat feature, or does this offer a solution to the stumbling block which has prevented this feature from being offered?Maybe I'm still missing something here, but nothing is occurring to me at the moment ... so if there's something else that's an issue in preventing this feature from being developed, please let me know. I'm very interested in continuing in this effort until PCS has a solution that we can start using soon ... Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://www.webdna.net
Associated Messages, from the most recent to the oldest:
>>Anyways, lots of other software does it: Panorama, FileMaker, BBEdit, >>Tex-Edit, etc. etc. > >No, they don't. They may change a *single* word at a time, but that's >significantly different from what you're asking. No it's not. They all change single strings of text, not just single words. And it's no big deal to change one match string at a time, then to run the process thru another cycle to change the second match string, then again to change the third, and so on until they have all been changed.I'm sure you know that performing this task by using a database of match strings would very much like using a founditems loop to perform a database field value replacement, as in this example:
[search] [founditems] [replace db=xxx.db&eqskudata=[sku]]from=[to][/replace] [/founditems] [/search]This example doesn't replace everything all at once, it sequentially replaces the from field with the [to] value in the first matching record, then in the second matching record, then in the third, etc. So why not use a similar technique for multiple match string replacements? there's no problem cycling thru any number of match strings. Granted, the more match strings there are, the slower the process will occur. But right now I could care less how slow it is, because right now it's not even possible! Maybe after it's possible we can start worrying about whether or not it's fast enough ...All I'm asking is to replace *one* match string at a time ... then when that ONE match string has been properly replaced in *each* position where it occur in the text, only then will webcat move onto the NEXT match string and replace ALL the occurrences of that SECOND second match string, one at a time, until they have all been replaced ... then on to the third match string, then on to the fourth, and so on ...This would work just fine ... but ...The method that's used to perform these individual 'find and replace' events in each cycle is the major issue here ... and this is something that needs to be done properly ...And that means NOT parsing from the beginning again each time a 'find and replace' event is performed, but instead, the text parsing for each SUBSEQUENT replacement must begin at the position immediately FOLLOWING the LAST replacement.This is the key to making this technique work properly, and I don't see the problem in implementing this technique ... is there one?Webcat should begin the process by parsing the original text until it 'finds and replaces' the FIRST occurrence of the FIRST match string in the database. Then it should perform its 'find and replace' event on that match string. Then it should simply continue parsing from that point (not from the beginning) until it finds the NEXT occurrence of the FIRST match string -- then it should replace that match string. Then it should continue doing the sate thing until it can no longer find the FIRST match string, which will definitely occur at the end of the text.Then when it gets to the end of the text, it would 'load' the SECOND match string and start over -- from the beginning this time -- performing the very same cycle of 'find and replace' events it just performed with the FIRST match string -- only this time it will do it with the SECOND match string.Then it would continue to perform this sequence of 'find and replace' events for each ADDITIONAL match string it finds in the database. And when it has eventually finished performing this same cycle with each of the remaining match strings in the database, it would output the results. This technique would result in the replacement of ALL the occurrences of ALL the match strings defined in the database -- without ANY chance of an infinite loop occurring. Because the only way an infinite loop can occur is if the parsing starts over from the beginning after every 'find and replace' event INSTEAD of after every match string 'cycle'.In other words, this proposed method of parsing, finding and replacing would do *exactly* what we want and need, without any possibility for error or crash (unless it requires more memory than webcat has made available to the thread performing this task -- but that's another issue entirely).As long as the 'find and replace' events do not cause the parsing to begin again from the beginning, the *deadly endless loop* problem I described previously cannot occur ...Are there other problems to be addressed in the design of this potential new webcat feature, or does this offer a solution to the stumbling block which has prevented this feature from being offered?Maybe I'm still missing something here, but nothing is occurring to me at the moment ... so if there's something else that's an issue in preventing this feature from being developed, please let me know. I'm very interested in continuing in this effort until PCS has a solution that we can start using soon ... Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://www.webdna.net
Kenneth Grome
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
[WebDNA] current thinking on architecture of mass email scripts? (2011)
OT: Amazon Patents (2000)
ExclusiveLock (2000)
Showif, Hideif reverse logic ? (1997)
searchable list archive (1997)
Using Cookie for client specific info? (1997)
WebCatalog for guestbook ? (1997)
[OT] IRC (2003)
[WebDNA] Easier to install versions! (2011)
WordBreak Qestion (part 2) (1998)
[WebDNA] Pretty URLS (2011)
WebCatalog Technical Reference (1997)
[WebDNA] Fwd: RETS... HELP! (2009)
randomness (1997)
Bug? (1997)
WebCat2 several catalogs? (1997)
Dates - Search and Sorting (1999)
Problem with broken images (2004)
Looking for a host (1997)
Speed Admin? (Was FlushDatabases) (1997)