Jump to content
Larry Ullman's Book Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ramasaig

  • Rank
  1. Thanks Larry. I've recently been working from a PHP/OOP/MySQL tutorial that used mysqli_connect syntax rather than PDO, so this may be why the author wrote an abstract table class with SELECT, INSERT UPDATE functions, etc. I'll revisit PDO. At least I have learnt something by making that work for me. I'll also have a go at a 'listings' class. Best Wishes,
  2. Hello Larry, Thanks for your reply. That makes sense to me. I guess I'll just have to feel my way from there. I don't think it's necessary to re-write my existing procedural code, but it may be easier to understand what I'm doing that way than starting with a new web site. It would seem my DB tables have a lot of common features (e.g. methods for SELECT, INSERT, UPDATE, etc.) so I'm thinking an abstract 'table' class might be the way to go, then each actual table class would extend the 'table' class? That's what I'm experimenting with right now. I can see that my abstract table class might be reused in another project, but the extended classes are going to be more project specific because they'll contain properties related to the fields in the DB, which may differ somwhat between projects. When it comes to displaying something from the DB (having selected), that would be a page class, perhaps? But it would be a very specific page (possibly with an HTML table, though not in all cases). One of my sites lists holiday accommodation, so it would seem 'listing' would become a templating class? Do I then have to have an object for each specific listing on the page? It's all dynamic, so the object names are going to have to follow from the listing ID. Example at: http://holidaymull.co.uk/scs-sw I know that's a lot of questions, and I'll understand if you haven't time to respond. I expect I can work out most of the answers in time! I really hope this sort of 'what do I do next' advice can be included in the new version of this book. Best Wishes,
  3. It's unfortunate that this posting didn't attract any replies (probably because it's too much of a rant). It does however reveal a real problem. I too have 'grown up' on Larry's books (and others by Sitepoint) that cover PHP and MySQL thoroughly in procedural code. I have created several web sites based on what I've learned. I'm now ready to move on to OOP, but despite reading about OOP and understanding the advantages I cannot get a handle on where to start re-writing my code. It's not even clear to me what I should choose as my classes. There's some guidance to be found on the web, but the tutorials I've found concentrate mainly on connecting to the DB using OOP and PDO, and only in passing on what to do after that. I came (back) to this forum to see if I could find out if the current edition of this book covers OOP and MySQL together. I've read the Contents (on Amazon) but that hasn't convinced me that I'll find what I'm looking for. Hence my search through the topics. I had thought that Larry had retired from book writing to take up employment, but I see there's a revised book coming out later this year, so perhaps there's hope yet? Tim Dawson
  4. Thank you for your replies. Passing a variable as a parameter is fine, but if (as in my case) you have many variables you either need to pass in or return, it can get cumbersome. The solution is to use arrays as Buttercream Cupcake says. I knew about using an array for 'return', but I hadn't realised one could also use an array as a parameter. BTW, I've come accross a PHP function 'compact' which I didn't know about before, for making an array out of existing PHP variables, so Buttercream Cupcake's example would become: $values = compact('nights', adults', 'teens', 'child2', 'child1', 'baby', 'cot_req'); Works a treat, and saves a lot of typing, including the awkward '=>' (requiring the shift key).
  5. Hello Larry, From my first encounter with PHP (from your various books) I've always understood that if one needs to use a variable in a function, when that variable was originally declared outside the function, then it must be declared as 'global' within the function. Similarly if a variable is created within a function and is required outside, it must be declared 'global' within the function (or 'returned'). (It may be that declaring it as global when originally declared also works, but I've not habitually done that) That has sometimes led me to declare a whole raft of variables as global at the start of a function. For example when I have a function to extract a lot of values from a MySQL database. Fairly obviously I want those values to be available outside the function. This can get cumbersome, and I'm sure I've declared globals I didn't actually need, just to be on the safe side. So I've been looking for ways to avoid 'globals' where possible. One way is to return an array of the variables and extract them. Some can be made arguments to the function, etc. In looking around forums and asking questions, it's become clear that a many people consider globals as 'bad' and to be avoided at al costs. Many of the solutions for doing so require OOP. I'm not yet comfortable with OOP (it's hard to find time to learn). So pro tem I'm stuck with procedural coding. For example, here's the start of a function to calculate the cost of a family staying at our Bed & Breakfast. The variables are those entered by the visitor to our web site when booking. Some will be zero (or empty or NULL). function calcBandbCost($link, $setYr, $rate) { global $nights, $adults, $teens, $child2, $child1, $baby, $cot_req; ... return $bb_cost; // an array with two items } The variables are in the main script (from $_POST), but I have to get them into the function. This seems the easiest way. I could extract $_POST in the function, but it contains other variables not neede by the function. I wondered what you thought about it ?
  6. Thanks for your comments. I took a few days off over Easter, but I'm back at this now (though not full time). I have managed to split up my control script into several modules. The 'index.php' file now consists of a 'cascade' of conditionals (mostly) applied to the $_GET query string, but in some cases to $_POST. Appropriate modules are called as required. The first task was to get it all working exactly as before (without Ajax), which I think I've achieved. The main search function is working well in Ajax, it's the smaller bits which are proving resistant at the moment. I should soon be in a position to upload a version to my test site (with partial Ajax), which I hope will make further discussion easier and more task oriented rather than generalisations.
  7. Hello HartleySan, Thank you for your response, and for taking the time to look at the non-Ajax site. The good news is that (just before reading your response) I have got the basic Ajax function working (So far I can update an accommodation search), showing the new listings. At the moment the Search Results summary (above the listings) isn't updating. I think this may require a second Ajax object, and I'll be looking into that next. You very properly question the need for such a long control script. The script handles almost everything the site does (there are few direct links between pages). This includes searches, several alternative DB calls (saving queries etc), visitor short-listing of search results, selection of template pages, and other stuff. I'm sure there's room for improvement, but essentially all that code has to be somewhere. If it's not in the control script it'll need to be in some included files. What the control script does is to filter any query string (or POST data) sent to 'index.php'. This might be a search as in '?ac[3]=BB&loc[2]=CT&save=accn&accns=Search' or a click-through from a listing such as 'locn=www.ardnacross.com/&id=2179' or a request for another page '?pages=eaglewatch'. POST data includes adding or removing from short-list, viewing and editing shortlist etc. However, all that is a digression from the original intention to ask about the best way to implement Ajax on this site. If I made another copy of the control script for Ajax purposes I'd quite possibly have to maintain two similar but different branches of code, which I'm reluctant to do. So it's still my intention to make the control script more modular (i.e using included snippets). In Ajax, because I'll know the nature of the query or POST data, I hope I need only call the appropriate snippet, not the entire script. (And who knows, if I apply that to the Ajax I may also be able to apply it to the non-Ajax. We'll see). I accept your comments about display in IE6. I've taken the possibly controversial decision not to continue supporting it. Visitors using IE6 are only 1.04% of the total. An additional reason is that I no longer have any means of viewing in IE6 myself (I could, of course, if I set up a virtual machine). Thank you for your help (and the encouragement that gives). Regards, Tim Dawson
  8. Hello Larry, Thanks for your reply. It's not that I WANT to feed the Ajax version through the control script, but I haven't worked out an alternative that will work. In the pre-Ajax version, almost every visitor click becomes a GET query string, and is fed into the control script which filters it and applies the appropriate action (from simple page request to DB searches and short-list building etc.). Search query strings are parsed into MySQL queries, and the returned results massaged into a PHP array and fed to the Search Results page template for display. (If the visitor starts on the home page this also requires a new page to be loaded). In the Ajax version I've successfully applied an 'onsubmit' event handler to the Search Box which produces the same query string (via JS) according to the checkbox selection. This too needs to be converted into a MySQL query and put through the same process as above. Hence the apparently simple option of feeding it into the control script. I will look into the possibility of simplifying the control script so that it still includes the filters, but the subsequent actions are in 'included' files, which can also be called directly by Ajax. I'm keeping in mind that it's still got to work with JS turned off. Thanks for your help.
  9. I run a web site http://www.holidaymull.co.uk that lists tourist accommodation and attractions. It's built using PHP and MySQL, and has an index.php control script. Every search (or other change) made by visitors calls the control script, and of course the page is refreshed (or a new page written) every time. See http://www.holidaymu...n/B&B/SouthWest for a typical search results page. (These links are to the NON-Ajax site, there's no public Ajax version yet) Most of the search results are displayed within the same template, and it would seem a natural for converting to Ajax. At least two separate areas of the screen need to be updated: first the results themselves, and second the short-list information (which, when present, shows above the results). The form(s) for users to select options are permanently in the left-hand column, and are just a series of checkboxes. I've attached an onsubmit event handler via JS. I have tried extracting parts of the control script and calling them via Ajax (togther with the code that actually displays the stuff), but the sections of the control script are so interdependent that although the Ajax part seems to work OK I don't get the results I want (there are always loads of PHP error messages referring to other parts of the control script that I've not included). The next thing I'm going to try is to create a 'control.php' file from all or most of 'index.php' script, and call that with Ajax (or even call 'index.php' itself, 635 lines of code). My thinking here is that since the non-Ajax version calls the control script every time it can't possibly be wrong to do the same in the Ajax version. Obviously I'll have to avoid having to maintain two versions of the control script. Does that seem a sensible approach, or can you suggest a better way ? Unfortunately (perhaps) re-designing the site from scratch isn't an option because of time constraints. Regards, Tim Dawson