 |
 |
 |
 |
 |
 |
 |
 |
 |
 Formatting
Found Records into a Table Let's fix that up by putting our found records into a table. This was our original code: [search db=listings.db&eqCITYdata=[_City]]
Address, City, Bedrooms, Bathrooms <BR><BR>
[founditems]
[Address], [City], [Bedrooms], [Baths]<BR>
[/founditems]
[/search]
Now lets put that into a table, to help our visitors actually enjoy looking at our data... [search db=listings.db&eqCITYdata=[_City]]
<table border="1" width="450">
<TR><TH>Address</TH><TH>City</TH><TH>Bedrooms</TH><TH>Bathrooms</TH></TR>
[founditems]
<TR><TD>[Address]</TD><TD>[City]</TD>
<TD>[Bedrooms]</TD><TD>[Baths]</TD></TR>
[/founditems]
</table>
[/search]
See how the standard HTML table tags can be intertwined into the WebDNA code? Pretty cool, and yet, still mostly readable. Remember, only the code inside the [founditems] tags loops, so you can put other code outside of it, but still inside the search. One more thing needs repeating: you can only access the fields of the database inside the founditems loop. I see people trying to use a data field right after a search tag from time to time, wondering why it isn't working. The reason it doesn't work is because WebCatalog doesn't know which record's data to show (even if only one record was found.) Ok, so what does the code above produce?
Nice. Now we can add a few more WebDNA tricks to the display. First, showing the city is really redundant! Also, we don't tell people how many records were found (it's obvious for this example, but learnin' is learnin' so indulge me, ok?) And, as a bonus for WebCat4 owners, we'll even play with a little hat trick that [search] affords us... [search db=listings.db&eqCITYdata=[_City]]
<table border="1" width="450">
<TR><TD colspan=4>We found <B>[numfound]</B> records that matched
your search for <B>[_city]</B></TD>
<TR><TH>Address</TH><TH>Bedrooms</TH><TH>Bathrooms</TH>
<TH>Square Feet</TH></TR>
[founditems]
<TR><TD>[Address]</TD><TD>[Bedrooms]</TD><TD>[Baths]</TD>
<TD>[Sq_Ft]</TD></TR>
[/founditems]
<TR><TD colspan=3 align=right>Average Square Feet:</TD>
<TD>[avg sq_ft]</TD></TR>
</table>
[/search]
All
of this gives us:
That's getting pretty nifty! Ok, let's see what we have here... the [numfound] tag shows, uhhhh, the number of records found for a search. So-so handy to show the website user, very handy for error checking the results (we'll cover this when we get to the [showif] context.) The [numfound] tag has to be used inside of a search, but outside of the [founditems] loop. Hmm, we're also reusing the [_city] text that was passed to us from the previous page. Notice in the code above, the case of the tag [_CITY] doesn't matter. This is a good thing for all you coding slobs. We have to reuse the _City value passed in, instead of the field CITY in the database, because we aren't inside the [founditems] loop yet. (Are you starting to see how this works?) And, the Hat Trick: the [avg] tag allows us to easily show the average value of a field in a database (OK, I have very little use for this, but some of you probabaly have a HUGE use for this, so- cool!) This example also shows why you would have a considerable amount of table code inside of the [search], but outside of the [founditems]. Ok, the results page is starting to look pretty nice, let's go add to the search page to make it easier to use... Embedded
Searches in Pulldown Menus <HTML> <head><title>Search for your future house</title></head> <body><form action="results.tpl" method="post"> Show houses in: <input type="text" name="_City"><br> <input type="submit" name="submit"> </form></body> </HTML> How barbaric! Even worse, the user may *gasp* enter a city which we don't have listings for! This is entirely unacceptable! We need to make this EASY for the user. Hmm, how to best do that...ah...ok, I've got it, we can make a pulldown of the local towns, thus eliminating user input error. Genius! Hmm, wait, being the lazy bum that I am, I suddenly realize that I have no desire to create a pulldown where I have to hand enter all of the names of the local towns, and even worst, someone could select a town that has nothing in it...thinking...another moment of Brilliant Insight™, what if we could have webcatalog create the pulldown from values stored in the City field of the database. This accomplishes two things: a) Wedon't have to type all of the towns in. b) the user can only select towns in which we have listings. Damn we're smart! OK, what we have to do is have a search embedded on this page, that is preprogrammed to look in the city field, and pull out each city, but just one time for each city (Unique values only). We can then push the found items into a standard HTML form pulldown. <body> <form action="results.tpl" method="post"> Show houses in: <select name="_City"> [search db=listings.db&neCITYdata=[blank]&CITYsumm=T] [founditems]<option>[city]</option>[/founditems] [/search] </select><input type="submit" name="submit"> </form> </body> Ok, so we've seen searches before. What's different here? The neCITYdata=[blank] is a good place to start. "ne" stands for Not Equal to, so we are looking for cities not equal to [blank]. That's about as clear as mud, huh? Let's try it this way... If we searched for cities that equal Parsippany, we'd get exactly one record (Parsippany). So we can search for cities that aren't Parsippany. This is done by saying neCITYdata=Parsippany. This limits us to all cities that aren't parsippany, but hey, we want all of the cities (Parsippany included). We could put in a dummy city (zootsville) but with my luck, there probably is a Zootsville somewhere in the US, so sooner or later this would fail. So instead, we put in [blank] which webcatalog reads as a record with that field (CITY) that contains no data. So, if we look for all records that are not equal to the field CITY that contains no data, then this is just an overly complex way of saying, search for all records in which the field CITY that contain data. Did that help? If not, write me, and I'll try to explain it again... Now that we've found the records in the database that contain some data in the CITY field (i.e. all the records of the database) we want to limit the [founditems] to just one instance of each city. CITYsumm=T accomplishes this. This would produce a pulldown like:
Nice. But hey, since it's only a few more seconds work, let's alphabetize the pulldown. To do this, all we have to do is change the [search] line to: [search db=listings.db&neCITYdata=[blank]&CITYsumm=T&CITYsort=1&CITYsdir=as]
Ok, the sort=1 with the field name tacked on tells WebCatalog which field we want to sort. You can have secondary and thirdary fields sorted, just by typing FIELDNAMEsort=2, or 3, etc, but it isn't needed for this example. The sdir=as command instructs WebCatalog to sort the City field in ascending alphabetical order. Technically, the sdir=as is assumed, but hey, this is a training document, so I've put it in to be strictly in accordance with the rules. Wow! we've got a somewhat functional website in just two pages. Where do we go from here? <-- Previous Index Next --> HOME | Basics | Advanced | Training | Rants+Raves | Links | Feedback This whole page, and everything on it ©2001 Brian B. Burton. This page and the text contained herein may not be reproduced on any other site, or via any other means. Really, how hard is it just to link to this site, so people get to see the latest updates? http://www.burtons.com/webdna/ Thank You. Site design by Clint Davis. Thank You Clint! |
||||||||||||||||||||||||||||||||||||||||