George J wrote: > ""Thiago Pojda"" <thiago.pojda@xxxxxxxxxxxxxxxxxx> wrote in message > news:004701c88a8a$eaab6480$0201a8c0@xxxxxxxxxxxxxx >> De: George J [mailto:georgejamieson@xxxxxxxxxxxxx] >> >>> So calling the script via the form works i.e it passes the >>> neccessary variables to constrct the sql query for the next >>> call. >> As Shawn said, if you really need the query again add it to session, >> never, >> NEVER give the user the ability to see/execute queries by himself >> (remember >> POST data could be easily manipulated). Remember what Daniel said, adding >> a >> DELETE FROM is not hard and veeery bad> > OK. I see the logic. > >> Ok, let me ask you something. Why post to itself? You could have a script >> only to do form actions, that way you can: >> 1 Separate huge php validations with your html form. >> 2 Use functions to handle the incoming data and writing the new query (or >> the old one again). > > I suspect that most folk in my position start the learning process by > finding a script that does a similar task and adapting it. This is basically > what I've done. I started by finding a form example and then added a > pagination routine then... Several deadends later... Not the best way to > write anything but the simplest of scripts. However, the numerous changes to > the code has entailed lots of learning during the process. So in answer to > your question. I didn't set out with any idea of the best way to write the > script. Just a broad idea of what I wanted to end up with. > >> As it's built at server side, the user is never going to see your query or >> [1]manipulate it as you're writing it all over again, just using your old >> parameters (they could be added as hidden fields in the form if strictly >> necessary). >> >> >>> So, as I see it, the pagination links won't POST the form >>> variables. How do I pass the 'SELECT * FROM mytable WHERE >>> selection=option LIMIT start, range' >>> query to the called script? >> You should try building a default query where you only add the parameters >> given by the user. If you can't seem to recover that, add them to >> $_SESSION >> and you'll be fine next time you want them (if you don't overwrite it >> =] ). >> > My query code- > > -------SQL query construction block > $query = "SELECT * FROM prods "; > if($catagory != 0){ // > if category != 0 > $where="WHERE c = $catagory "; > if ($manu != 0){ // check > manu != 0 > $and = "AND m = $manu "; > if ($searchstring != 0){ > $and = $and."AND description LIKE \"%$searchstring%\" "; // > check like != 0 > } > }else{ > ... > $query=$query.$where.$and.$like > > ----------- > Can you please explain your suggestion above in laymans terms. I can't see > what you have in mind. Is it your suggestion to use one script, containing a > from, that calls another script that handles my query construction? That far > I follow you but what happens next? > > > What file is this? is the pagination code in this file also? If not where? Post you pagination code and this is a simple explanation. Build your query as you've done and stick it in a session var. It is now available to future calls to this page or other pages. -Shawn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
