Combining php include and $_GET

[FromCary]

I am creating a website for our home improvement company and I would like to create a glossary of terms that most people are not familiar with.  I want visitors to be able to click on certain terms within the context of the article they are reading and a new window pops up with the definition.  For example, if they click on the word “R-Value”, the page http://www.ourwebsite.com/glossary/index.php?term=rvalue will pop up in a new window.  I’ve got all that figured out.  But now it gets complicated.

 

I do not want to use a database for this, so I have decided to use individual text files for each term.  So when the visitor clicks the link above, I want the text file containing the definition of R-Value to be included into the page like this:

 

<?php include ("../glossary/rvalue.txt"); ?>

 

But if I put a link to http://www.ourwebsite.com/glossary/index.php?term=energystar, I want the energystar.txt file to be included using:

 

<?php include ("../glossary/defs/energystar.txt"); ?>

 

I would like to use the $_GET command to make it so that whatever is in the “term” parameter in the url defines which text file gets included.  But I don’t know how to use $_GET within an include command.

 

I hope I have explained my problem well enough.  I would be happy to clear anything up if I have confused anyone.  If anyone can tell me how to accomplish this, I would really appreciate it!

[thangappan]

It is quite easy.

 

First use GET method in PHP. While loading to this page check the value of

term using $_GET variable as $_GET['term'].

 

Then you can use one associate array. for storing all the keywords and url associated with that key.

 

For an example,

 

$assoc_array = array("energystar" => "http://www.ourwebsite.com/glossary/index.php?term=energystar");

 

Then redirect page using javascript option(window.location) as

$val = $_GET['term'];

$url = $assoc_array[$val];

echo "<script type=\"language\">window.location($url); </script>

 

[FromCary]

I'm pretty new to php, so I'm afraid I don't understand what you're saying I should do.  Can you explain it in a little more detail?  I appreciate you taking time to help!

[trq]

See the first example here.

[FromCary]

I think I get it.  I'll play around with it and see what happens.  Thanks for you're help!

[Lodius2000]

also, if its an option, use a db, that way you can load a dynamic array of the list of terms, so that say 6 months down the line you realize the term 'pressure treated' was never included in the list of terms, so you have to go make a term page for it, then you have to append the list of terms, then ou have to make the link to that page...

 

or with a db, you make a new row in the table

term = pressure treated

def = definition

 

then on the terms list page, you SELECT terms FROM definitions_table

 

foreach($terms as $term){

echo "<a href=\"path/to/terms/page.php?term=$term\">$term</a>";

}

 

see how easy that was you spend a little more time on the setup (ie making a create_new_term.php) and the later on down the line becomes sooo much faster and easier

 

hope that sways you

[ialsoagree]

I agree with Lodius, in the end a database will probably manage this better for you.

 

While the over head of connecting to a database may seem an over burden, in the end a large list of terms will be better managed by MySQL selecting the exact term for you than PHP defining a huge array of terms and definitions and then picking out the one the user requested.

[Lodius2000]

correct me if im wrong but functions like in_array are wayyyyy slower than SELECT term FROM definitions_table WHERE term = $term

 

//just trying to figure out how he would do the links if they linked to static files

[ialsoagree]

It really depends on the size of things, but as size increases, yes that is the case.

 

The primary reason is that there's over head to connect to the database server and get a response. As the overall size of the table/array gets bigger, the database becomes significantly more effective at processing the contents (a database checks the table index for the contents of the where clause, it then goes straight for the record and returns it, in_array has to check all the indexes for the needle).

 

I'm assuming this person is defining (in PHP, not in a text file that has to be loaded) an array. Defining the array is going to be extra over head (although not much). Still, it's a whole list of variables defined, and then you tell PHP to search for just 1 of them. It's kind of a backwards way of doing it. You start by creating a huge haystack when you only needed 1 piece of straw, then you have to find that piece of straw.

 

I don't mean to sound offensive though, I just wanted to point out the logical process I see going on. If the array remains relatively small it actually might be faster to do it all in PHP and keep a database out of the picture.

[FromCary]

Thanks to everybody for your help!  I have got it working with text files right now.  I don't think the array will grow big enough to warrant a database, I doubt I will need to provide definitions for more than 20 or 30 terms.

[Lodius2000]

i agree ialsoagree,

 

small haystack=faster than db

 

but FromCary is taking the collective product descriptions of a home depot and putting them into individual textfiles, then storing an array with their names somewhere in a static text file and then linking to the a php file that loads the text file as an include, but Im sure the GET var searching througha huge directory of text files rather than loading 1 row from a db, I think in this case a db would be way faster

[Lodius2000]

Cary... you sure 20 or 30, I work at home depot and the home improvers there can ask me about 30 different things in a few minutes

[ialsoagree]

A text file gives you roughly the same over head as a MySQL database anyway.

 

Loading the file + formatting the text into an array will take roughly the same time as connecting to a database, searching, and returning a row.

 

Not to mention, the former way requires in in_array function as Lodius points out, in the end, it'll be much slower, especially for 20-30 items.