Re: [WebDNA] maybe silly suggestion? [founditems]

This WebDNA talk-list message is from

2015

It keeps the original formatting. numero = 111909
interpreted = N
texte = --54b811ee_625558ec_12aContent-Type: text/plain; charset="utf-8"Content-Transfer-Encoding: quoted-printableContent-Disposition: inlineKen -I think the key items for me include:=E2=80=A2 =5Blistfounditems=5D would have access to all the fields in the= database that was searched=E2=80=A2 You could reuse the found item set multiple times in you page w=ithout the expensive search=E2=80=A2 You could have multiple found item sets for the same database w=ithout the potential confusion caused by nested searches=E2=80=A2 The search code would not need to know anything about what the =display code will be doing with the results=E2=80=A2 The syntax would be cleaner than doing this by generating =5Bta=ble=5Ds for later access, which is the closed current analog to this conc=ept=E2=80=A2 Built into the WebDNA engine, this could be much more efficient= than creating a set of functions to implement similar featuresIn my mind, features should be added to WebDNA if and only if they add va=lue that cannot be easily and efficiently implemented using functions. I =think this qualifies.=E2=80=94 Brian =46riesOn January 15, 2015 at 10:57:34 AM, Kenneth Grome (ken=40webdnasolutions.=com) wrote:Sorry but I find nothing of value in any of these suggestions that =20have to do with savefounditems or listfounditems or displayfounditems. =20> With =5Bsavefounditems=5D, you could save several sets of searches =20> on the same database ... =20We can do this now simply by setting =5Btext=5D variables in searches =20at the top of the page. =20> Given a page with formvariables =E2=80=9Cfirstname=E2=80=9D and =E2=80=9C=city=E2=80=9D, the top of your code could do: =20> =5Bsearch people.db&eqfirstnamedatarq=3D=5Bfirstname=5D&allhit=3D1&last=namesort=3D1&max=3D25=5D =20> =5Bif =5Bnumfound=5D=3D0=5D=5Bthen=5D =20> DO ERROR STU=46=46=5D =20> =5B/then=5D=5Belse=5D =20> =5Bsavefounditems namepeople=5D =20> =5B/else=5D=5B/if=5D =20> =5B/search=5D =20Or we can do this now without any special new tags, like this: =20=5Bsearch ...=5D =20=5Bif =5Bnumfound=5D=3D0=5D =20=5Bthen=5DDO ERROR STU=46=46=5B/then=5D =20=5Belse=5D =20=5Btext=5Dnamepeople=3D=5Bfounditems=5D=5Bfirstname=5D, =5B/founditems=5D==5B/text=5D =20=5B/else=5D =20=5B/if=5D =20=5B/search=5D =20Then further on down the page: =20People named =5Bfirstname=5D: =5Bnamepeople=5D =20I do things like this all the time on order to keep complex code =20at the top of the page and simplify my HTML which appears at the =20bottom of the page. Therefore I do not understand how your =20suggested new tags can provide us with any feature that is better =20or more useful than what we already have at our disposal. =20But if I am missing something please feel free to explain it in a =20different way, then maybe I will =22get it=22. =20Regards, =20Kenneth Grome =20WebDNA Solutions =20http://www.webdnasolutions.com =20Web Database Systems and Linux Server Management =20On 01/15/2015 12:27 PM, iPhonzie=40G wrote: =20> I really like the idea of =5Bsavefounditems=5D / =20> =5Bdisplayfounditems=5D (or maybe =5Blistfounditems=5D for consistency ==20> with other looping context names). =20> =20> Chris, if your =5Bsto=5D concept is about persistent globally =20> available values, then I don=E2=80=99t think that applies to the need =20> here - the saved results generally only need to persist for the =20> life of the current page. =20> =20> Internal to the WebDNA engine, this may well leverage the same =20> code as =5Btable=5D - the =5Bsavefounditems=5D could create a private =20> table and =5Blistfounditems=5D could execute a generic unranked =20> search of that table =20> =20> With =5Bsavefounditems=5D, you could save several sets of searches =20> on the same database, such as =E2=80=9Cpeoplenameddave=E2=80=9D and =20> =E2=80=9Cpeoplefromalbuquerque=E2=80=9D, gathered at the top of your pa=ge with =20> appropriate error responses, etc. Later in the display portion =20> of your page you could call a common function to display HTML =20> tables of Daves and Albequerqians. =20> =20> So, given a page with formvariables =E2=80=9Cfirstname=E2=80=9D and =E2==80=9Ccity=E2=80=9D, =20> the top of your code could do: =20> =20> =5Bsearch =20> people.db&eqfirstnamedatarq=3D=5Bfirstname=5D&allhit=3D1&lastnamesort=3D=1&max=3D25=5D =20> =20> =20=5Bif =5Bnumfound=5D=3D0=5D=5Bthen=5D =20> DO ERROR STU=46=46=5D =5B/then=5D=5Belse=5D =5Bsavefounditems namepeopl=e=5D =20> =5B/else=5D=5B/if=5D =5B/search=5D =20> =20> =5Bsearch =20> people.db&eqcitydatarq=3D=5Bcity=5D&allhit=3D1&lastnamesort=3D1&firstna=mesort=3D2&max=3D25=5D =20> =20> =20=5Bif =5Bnumfound=5D=3D0=5D=5Bthen=5D =20> DO ERROR STU=46=46=5D =5B/then=5D=5Belse=5D =5Bsavefounditems citypeopl=e=5D =20> =5B/else=5D=5B/if=5D =5B/search=5D =20> =20> =5Bfunction name=3Dshowpeople=5D =5Blistfounditems =20> =5Bparams=5Fstring=5D=5D =20> =20> =20> =5B/listfounditems=5D

=5Bindex=5D=5D

=5Bfirstname=5D

=5Blastname=5D

=5Bcity=5D

=5Bany =20> =20> =20field in people.db=5D

=5B/function=5D Later in the display =20> code you could do: =20> =20> People named =5Bfirstname=5D: =5Bshowpeople namepeople=5D =20> =20> People from =5Bcity=5D: =5Bshowpeople citypeople=5D =20> =20> =20> =E2=80=94 Brian =46ries =20> =20> On January 15, 2015 at 9:55:07 AM, Terry Wilson =20> (terry=40terryfic.com ) wrote: =20> =20>> Or just put the search parameters in a variable up top to =20>> retrieve as needed with showifs. This is quite handy for =20>> repurposing found items loops, such as a nicely formatted =20>> table of info that is sorted by various fields (just =20>> discussed this a few days ago). This has the added benefit of =20>> letting you keep constants like eventdatetype=3Ddate, max=3D25, =20>> etc in the actual search code to keep your parameters easier =20>> to read and manage. This would certainly put your controller =20>> logic separate from your display code. =20>> =20>> =5Bshowif =20>> =5Bsomesearch=5D=3Dt=5D=5Btext=5Dsearchforwhat=3Ddb=3Dallthethings.db&=blahblahblah=5B/text=5D=5B/showif=5D =20>> =20>> =20>> =20=5Bshowif =20>> =5Bsomeothersearch=5D=3Dt=5D=5Btext=5Dsearchforwhat=3Ddb=3Dallthething=s.db&blahblahblah=5B/text=5D=5B/showif=5D =20>> =20>> =20>> =20>> =20=5Bsearch =5Bsearchforwhat=5D&max=3D25&lastnamesort=3D1=5D =20>> =20>>> =20>>> =20>>> On Jan 14, 2015, at 2:57 PM, Brian Burton =20>>> wrote: =20>>> =20>>>> to help separate my controller logic from my display code =20>>>> it would be awesome to have a shortcut like: =5Bsearch =20>>>> db=3Dallthethings.db&blahblahblah=5D=5Bsavefounditems =20>>>> name=3Dpeoplenameddave=5D=5B/search=5D =20>>>> =20>>>> =20>>>> =20>>>> =20>>>> then later in the page, where i=E2=80=99m rendering the html =20>>>> =5Bdisplayfounditems use=3Dpeoplenameddave=5D html things =20>>>> =5B/displayfounditems=5D =20>>>> =20>>>> =20>>>> =20>>>> I know it looks like it=E2=80=99s not saving that much code, but =20>>>> I can see switching which search I want in the =20>>>> controller, and still being able to use a universal =20>>>> founditems loop lower in the code. Also the ability to =20>>>> reuse search results (if needed) without doing the same =20>>>> search again. =20>>>> =20>>>> ok, feel free to start telling me how you can do this =20>>>> with a table (you=E2=80=99re missing the point) or how we don=E2=80=99=t =20>>>> need more tags or whatever :) =20>>>> =20>>>> =20>>>> -Brian B. Burton =20>> =20> --------------------------------------------------------- This =20> message is sent to you because you are subscribed to the =20> mailing list . To unsubscribe, E-mail to: archives: =20> http://mail.webdna.us/list/talk=40webdna.us Bug Reporting: =20> support=40webdna.us =20--------------------------------------------------------- =20This message is sent to you because you are subscribed to =20the mailing list . =20To unsubscribe, E-mail to: =20archives: http://mail.webdna.us/list/talk=40webdna.us =20Bug Reporting: support=40webdna.us =20--54b811ee_625558ec_12aContent-Type: text/html; charset="utf-8"Content-Transfer-Encoding: quoted-printableContent-Disposition: inline