2015

> [listfounditems] would have access t=o all the fields in the
> database that was searched

Are you suggesting that [listfounditems] cache the results of theoriginal search?=C2=A0 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?=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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?=C2=A0 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.=C2=A0 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.web=dnasolutions.com
Web Database Systems and Linux Server Management




----------------------------=-----------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us&g=t;.
To unsubscribe, E-mail to: <talk=-leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us