Re: [WebDNA] maybe silly suggestion? [founditems]
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 111920
interpreted = N
texte = From what I understand, Brian wants his founditems contexts to work outside his search context, but because this is not the way WebDNA works he wants new tags/contexts to implement it. Is this correct Brian? Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Management On 01/15/2015 02:20 PM, Dan Strong wrote: > Gotta admit that I agree with Ken and have from the start. I am > not seeing the value of this either, but maybe I just don't "get > it" either. > > Also looking forward to a concrete use case/example to help me > understand the concept a bit better. > > -Dan Strong > http://DanStrong.com > > On Thu, Jan 15, 2015 at 12:10 PM, Kenneth Grome >
> wrote: > > > [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 > > > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list >. > To unsubscribe, E-mail to: > > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > > > --------------------------------------------------------- This > message is sent to you because you are subscribed to the mailing > list . To unsubscribe, E-mail to: archives: > http://mail.webdna.us/list/talk@webdna.us Bug Reporting: > support@webdna.us
Associated Messages, from the most recent to the oldest:
From what I understand, Brian wants his founditems contexts to work outside his search context, but because this is not the way WebDNA works he wants new tags/contexts to implement it. Is this correct Brian? Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Management On 01/15/2015 02:20 PM, Dan Strong wrote: > Gotta admit that I agree with Ken and have from the start. I am > not seeing the value of this either, but maybe I just don't "get > it" either. > > Also looking forward to a concrete use case/example to help me > understand the concept a bit better. > > -Dan Strong > http://DanStrong.com > > On Thu, Jan 15, 2015 at 12:10 PM, Kenneth Grome > > wrote: > > > [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 > > > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list >. > To unsubscribe, E-mail to: > > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > > > --------------------------------------------------------- This > message is sent to you because you are subscribed to the mailing > list . To unsubscribe, E-mail to: archives: > http://mail.webdna.us/list/talk@webdna.us Bug Reporting: > support@webdna.us
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:
Database Updates (1997)
Assigning carts (1998)
New: [WebDNA] Help with ReplaceFoundItems (2009)
[quantity] and quantity[lineindex] (2000)
Linux DB problems (2000)
Close Databases Crash? (1998)
Redirect frame targets (1998)
Resume Catalog ? (1997)
email error 159 (1998)
[searchString] (1997)
Summing fields (1997)
WebCat2b12 CGI Mac -- Problems propagating the cart through (1997)
add line item context and showitems (1998)
[format] problem (2001)
Formulas What if. (1999)
Problem: 3.0 doesn't update carts (1997)
Proper file locations (1997)
Secure server question (1997)
Calculating multiple shipping... (1997)
searching multiple databases in single search (1997)