Re: [WebDNA] maybe silly suggestion? [founditems]
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 111915
interpreted = N
texte = > [listfounditems] would have access to all the fields in the > database that was searched Are you suggesting that [listfounditems] cache the results of the original search? If so, this means that each time the page is requested WebDNA must cache a new copy of the founditems data, correct? And how this data going to be formatted? OR is this new context there simply to allow you to use [fieldname] tags -- which we can already do in our [founditems] contexts? > You could reuse the found item set multiple times in you page > without the expensive search. I'm not sure why do you use the term "expensive" here ... If you're currently using more than one identical search per page you're not doing it very efficiently. The better way is to do one search and then use several founditems contexts within that one search context. I do this all the time. I put several founditems context inside my search, then I format the results of each founditems the way I need it to be displayed further on down the page. Then I save the formatted results of each founditems as a text variable, which means I can display the entire formatted results with a simple text tag like [results1]. This means I'm doing only one search on the page -- and one search is certainly not "expensive" from my perspective. > You could have multiple found item sets for the same database > without the potential confusion caused by nested searches I almost never do nested searches anyways since there are better ways most of the time. > The search code would not need to know anything about what the > display code will be doing with the results This is nothing different that what we already have with [founditems], is it? If so, how is it different? > Built into the WebDNA engine, this could be much more efficient > than creating a set of functions to implement similar features Yet if we do not need these capabilities -- because we already have them -- we do not need to use functions, and we do not need to further complicate the engine code either, correct? > In my mind, features should be added to WebDNA if and only if they > add value that cannot be easily and efficiently implemented using > functions. I think this qualifies. Sorry, I still disagree. I have yet to see anything you've described or shown me that I cannot do right now with [founditems] and [text]. I'm not trying to be difficult but I truly see no advantage in any of this. Can you show me a concrete example where using multiple founditems and text vars won't do everything you're suggesting? Because so far I still don't get it. Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Management
Associated Messages, from the most recent to the oldest:
> [listfounditems] would have access to all the fields in the > database that was searched Are you suggesting that [listfounditems] cache the results of the original search? If so, this means that each time the page is requested WebDNA must cache a new copy of the founditems data, correct? And how this data going to be formatted? OR is this new context there simply to allow you to use [fieldname] tags -- which we can already do in our
[founditems] contexts? > You could reuse the found item set multiple times in you page > without the expensive search. I'm not sure why do you use the term "expensive" here ... If you're currently using more than one identical search per page you're not doing it very efficiently. The better way is to do one search and then use several founditems contexts within that one search context. I do this all the time. I put several founditems context inside my search, then I format the results of each founditems the way I need it to be displayed further on down the page. Then I save the formatted results of each founditems as a text variable, which means I can display the entire formatted results with a simple text tag like [results1]. This means I'm doing only one search on the page -- and one search is certainly not "expensive" from my perspective. > You could have multiple found item sets for the same database > without the potential confusion caused by nested searches I almost never do nested searches anyways since there are better ways most of the time. > The search code would not need to know anything about what the > display code will be doing with the results This is nothing different that what we already have with
[founditems], is it? If so, how is it different? > Built into the WebDNA engine, this could be much more efficient > than creating a set of functions to implement similar features Yet if we do not need these capabilities -- because we already have them -- we do not need to use functions, and we do not need to further complicate the engine code either, correct? > In my mind, features should be added to WebDNA if and only if they > add value that cannot be easily and efficiently implemented using > functions. I think this qualifies. Sorry, I still disagree. I have yet to see anything you've described or shown me that I cannot do right now with
[founditems] and
[text]. I'm not trying to be difficult but I truly see no advantage in any of this. Can you show me a concrete example where using multiple founditems and text vars won't do everything you're suggesting? Because so far I still don't get it. Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Management
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:
Unexpected comparison behavior change in 4.5.1 (2003)
WebCat2 beta FTP site (1997)
replacing items in a db (2000)
Almost a there but..bye bye NetCloak (1997)
Country & Ship-to address & other fields ? (1997)
WebCatalog2 Feature Feedback (1996)
Nested search (1997)
Setting up shop (1997)
Initiating NewCart (1997)
Roundup function? (1997)
Gremlins, huh? (2000)
Commitdatabase tag (1998)
cr/cr/lf under WebSite ($WebCat.exe) confirmed (2000)
Kill the webcat process (2000)
Make sure I understand this??? (1997)
WebCatalog 4.0 has been released! (2000)
URL for Discussion Archive (1997)
[WebDNA] Deliminating encrypted values (2008)
[WebDNA] Converting minutes to hours (2008)
A quickie question (1997)