HartleySan

Yeah, things are a little vague. I'm not familiar with that HTML/PHP editor. Sorry. Like Jonathon said, if you could please post your code, that would be helpful. However, if your code is identical to the code and the book (and you're sure that there are no syntax errors), then the issue might be with the setup of your PHP editor. Personally, I prefer to use XAMPP (a free program that provides a virtual server) and a separate text editor (I prefer Notepad2). Again, it's hard to know the issue for certain without looking at your code, but if you just copied the code from the book, then it's probably an issue with your test environment (i.e., some settings in Rapid PHP 2007).

Was just about to say that it's probably a magic quotes issue, but then you answered it yourself. Nice work.

Understandable. Well, I hope you learn a lot.

Yeah, time is usually the limitation when it comes to these things. I think another (somewhat unfortunate) circumstance that comes up is where your boss (who knows nothing about IT or the web) gets convinced by a bunch of salesmen that product XYZ is the best product for the job, so you're therefore required to learn how to use that product regardless of whether it's the best or not. Luckily, in the case of Flex, while it more or less mirrors what Ajax can use, it is a good product, and definitely has its benefits.

Well, one thing I can say for certain, if I were a programmer at a company, and my company wanted me to build some sort of system for internal use, I'd probably opt for Flex over HTML/CSS/JS any day of the week. It's just so much easier to quickly create and organize all the components you need. Plus, Adobe takes care of most of the nitty-gritty for you, and you don't have to worry about cross-browser issues, etc. Basically, it's a lot easier. I suppose that's the best way to put it. That said, I think I still opt for the standard Ajax combo for websites to submit to the world, etc.

Sure, I understand, and I figured it was more for the sake of learning than anything. Generally, those that come from a C++/Java background what to do everything OOP, which is all fine and dandy, but it's not necessarily required. Also, yeah, what you want to do is completely practical; add/edit player info in the database by simply passing arguments to a setter function. You can also use things like stored procedures though, which will allow you to add an extra level of security and speed to your site/app. Anyway, I suppose this is true regardless of the content, but when you say you want to manage all that EU football stuff, I would think you'd simply want to be able to display and sort data, and then by clicking on a player, edit that players content. If that's the case, you really don't need OOP. However, like you said, you're doing it to learn, and that's totally fine. If that's the case though, I'd take the getAllPlayers method out of the Player class. Remember that the methods should be for acting on individual players (if you go OOP on this).

Not replying on Larry's behalf, but I will offer my two cents: Basically, I don't think there is any definitive answer. Flex is like Flash for applications, as opposed to more graphic-oriented things. With that said, similar to Java's Virtual Machine, with Flex, as long as someone has Flash, they can view the content, and it will look consistent, regardless of the OS and browser. I think that's a big selling point for Flex: consistently across platforms. Likewise, if someone installs AIR, they can run the programs as desktop applications as well. Also, Flex has a lot of libraries, which make it easy to create what you want. Well, I'm sure Larry will have more to offer to the discussion than that. I'll also ask my friend Matt, who sometimes participates on these boards to chime in, since his area of expertise is Adobe technologies, such as Flash and Flex. Edit: A lot of people are saying that HTML5 is gonna be the downfall of Flash/Flex, but that's a long way off (if at all), I think. Show me at what point HTML5 can directly access the hardware on a computer (like Flash/Flex can), and also show me HTML5's replacement for Flash video, which runs on all sites such as YouTube, etc., and I'll say maybe. Like I said though, it's a long way off (if at all). I suppose the dream off "one Web language to rule them all" isn't all bad, but we're not there yet.

I don't see this code on page 258, but anyway, I think your interpretation is correct: There is an array called quantity in the POST superglobal. The SKUs are the indices, and $qty is the value of those SKUs (the number of items available for that SKU). Then the SKU is broken up into two parts, the $sp_type (I guess the product type) and the product ID. After that, if both of those are set, then quantity is checked to see whether it is a valid, positive integer (i.e., an integer starting from 0). If it is, then $qty remains unchanged, but if, for some reason, $qty is not an integer or is negative, then it's set to 1. I guess the point is that the thing being evaluated in the ternary operation is the filter_var function with its arguments. Hope that makes sense.

Thanks for that info.

To be honest, things like getters and setters are quite often not necessary for small projects that only you're working on. For that matter, OOP is often not necessary in PHP either. Hehe! Don't mean to get you down; I know you're trying to learn this stuff. I don't mean to say that OOP is worthless, but it has it's place. To answer your question, getters and setters are very valuable for large projects and modules, etc. Getters and setters allow you to achieve encapsulation, which is a huge perk of OOP. Basically, if you release a library/module that doesn't use getters/setters, a bunch of people start using that library, and then you decide to upgrade that library at a later time, since the people using the library are directly accessing all your class variables, if you change any of them, the users using your old library cannot upgrade without having to change a lot of their own code. That's bad! Instead, by using getters and setters, the method for retrieving information on the library-user's end is always the same, even if you decide to edit the actual inner-workings of the class at a later time. For example, maybe you decide to add validation steps to a variable in your class. That's easy to do when using getters, setters and encapsulation, and you don't have to worry about messing up other people's code. I hope that makes sense. Years ago, when I first learned about the whole public/private/protected thing and encapsulation thing in C++, I didn't get the point, but that's because I had never worked on any huge projects. I think that's the bottom line though: OOP definitely has it's place, but for my own uses at home, making my own small sites, it quite often isn't necessary. There are, of course, those hardcore programmers out there that insistent that you always have to use OOP, but in general, OOP adds another level of abstraction, complexity, and is actually slower than a traditional procedural approach. Back to answering your questions, you'd probably use getters and setters with database info in the sense that you'd retrieve data from a database, store it in a private variable, and after potentially messing with the data in the variable, allow the variable to be accessed via a getter and setter. In the end, if you want to go OOP, you'll want a way of automatically generating hundreds of players on the fly quickly and easily. Then, you can access any "player", and use the native methods attached to the player objects. Personally though, unless you're planning on making this for other people to use, I would probably just directly grab all the necessary data from a database, and edit/display it as necessary. Basically, I wouldn't go OOP with it. It's up to you though.

Jonathon makes a lot of good points. The web is constantly changing at such a pace, it's hard to keep up. I do think that Ajax is here to stay for a while though. The only alternatives to Ajax for dynamic content are things like Java and Flash, which require completely separate APIs (which are generally expensive), and are not natively supported by all browsers. I'm not putting those languages down, but for websites, I still think Ajax is the best option to go with, and the most important one to know. I mean, the entire Google empire was built on mad JavaScript/Ajax and regex skills. And yeah, similar to Jonathon, I went from Larry's PHP 6 & MySQL 5 book to the Ajax book, and it wasn't too bad. When he got into certain parts of JavaScript and creating XML data, it was a bit confusing at times, but you can always come to this forum and ask, or find other resources on the web. Also, I really don't think that O'Reilly books are for beginners. I consider myself of an intermediate skill level in JS, PHP, etc., and still, I can't understand some of the things they talk about. Also, I'm not a mind reader, but another thing I think that is hear to stay for a while is jQuery. I avoided it for a while, because while it does admittedly make a lot of JS techniques a lot easier, I'm not big on external libraries, and also, you still have to learn it, easy or not; you still have to memorize new syntax, function names, etc. It can be tricky, especially if you JavaScript-fu is weak. In the end, I think that picking up Larry's Ajax book and just studying the basics of JavaScript would be your best bet for now.

Yeah, it's as good a place as any, I think. And as you probably know, Ajax is not a language, per se, but a technique of using JavaScript and a server-side language (generally PHP) together to dynamically load content. And yeah, I suppose it is a bit ironic that we still turn to books, but there is something nice about being able to actually hold something in your hand. Also, while things like Amazon's Kindle are nice, I still prefer text on a page, as opposed to text on a screen.

Antonio, I think you hit the nail right on the head. No one should ever be able to view user passwords, yes.

chop, interesting process you gotta deal with there. If you wanna go Antonio's route, certainly, that wouldn't be bad. If you still wanna go the Ajax route though, I don't mind helping. In order to do that though, you'll have to give us some idea of how you're planning on making the form interact with the database (as your situation is rather unusual, I think).

I don't know of any off the top of my head, but that certainly doesn't mean they don't exist. Tell ya what though, as a challenge to myself, if you want to send me the structure of your database, I'll write some code for you and send it back. I'm thinking the best approach is to grab all the data on page load (since there probably isn't that much), and then store it in a JavaScript object for later use. Also, what's your time frame on this? Based on that, I can take the time to help explain things to you. My email address is hartley.84@gmail.com, if you're interested.

ToolJob, you can use any sort of JavaScript event to trigger an Ajax request to a PHP script to get information. Be aware that if you, for example, attach an onclick event to an a tag, you need to return false, in order to squelch the default behavior of the browser wanting to follow the href in the a tag. Sorry for the brief response, but in a bit of a hurry. If you want more specific information, just ask.

Wow, Paul, that's a great question! It also brought a bit of a tear to my eye, in the sense that I used to be in the exact same boat as you. While I'm no expert at JS, and I am always studying to learn more, I do feel like I have finally gotten to a point where I understand it pretty well, and honestly, it's been a painful journey at times. I have to admit that one of my great frustrations recently has been that there seem to be no great, all-encompassing, one-stop JS resources out there. Perhaps the closest thing would be ordering a book off of Amazon. Perhaps read customer reviews, and pick the one that best fits what you want. I did buy the O'Reilly book off of Amazon, and while admittedly the ultimate JS reference resource, it is not for beginners, I think. I had to skip over a lot, and then come back to it later, after finally increasing my understanding through other means. And on the Internet side of things, the same thing seems to be the issue; no great one-stop shops. I personally have had to piece together my knowledge from various resources and thinking about things a lot. It's quite frustrating too, in the sense that JS is quite possibly the most important webpage language today, but no one seems to explain it well. That's partially why I have hoped so long for a JS book from Larry. I have no doubt that Larry would explain it as well as he does PHP, etc. With all that said, I think the best approach is to ask yourself what you want to do, and then go out there and try to learn how to do it. In doing so, you'll slowly pick up different pieces of JS, and also learn more about what exactly JS is even used for. I personally started with Larry's Ajax book, as the ability to add dynamic content was very appealing to me. As I went through the book, if there was something I didn't understand, I would either ask on these forums, or research it like a madman until I found an answer. Perhaps that's the best advice I can give. Certainly, I think this forum is a great resource, and I urge you to continue to ask questions whenever you're stuck. There's also a board just for Larry's Ajax book. Well, could talk about this for hours, but gotta get ready for work. Hope that helps.

chop, there are a couple of things you can do. Assuming that you're grabbing the info from a database, you'll need PHP. However, in order to actually update the second box on the fly based on the first box, Jonathon is right, you will need JavaScript. You could either load all the info, and store it in a variable for JavaScript to use when the page is loaded, or you could make an Ajax call when an item is selected from the first list. It's your choice. Feel free to ask for more information, if you need it. Edit: I should add that even if you decide to grab all the data on the page load, you should still probably use Ajax to get the data.

Good, good. Glad it all worked out. And really, I think that is the best method.

I would review Larry's discussion of handling passwords in the book, but when a user first registers and sets their password, you should be using a hash function (such as SHA-1) to make it indecipherable before putting it in the database. At that point though, you have no way of ever getting the original password again, and you can only verify whether passwords are the same by comparing their SHA-1 values. With that said, if a user forgets their password, you pretty much need to send them a new (random) password, which they can use to log in, and then change the password as they see fit. Anyway, I think the biggest thing you need to consider right now is the implementation. I would recommend re-reading the relative sections in the book, as Larry pretty much does it all for you. Edit: As for comparing an entered password with a password in a database, you'd have to do something like the following: $password = $_POST['password']; $q = "SELECT password FROM ... WHERE password=SHA1('$password')";

If you want to create an instance of the class for each player, you'd have to declare a variable for each player, such as: $Pele = new Players(arguments-here); $Ronaldo = new Players(different-arguments-here); Anyway, not sure what your intentions are, but you might want to take the getAllPlayers method out of the class, and then use that function to create an array of all the players on the fly. If you do that, your getters and setters should work fine.

You're making the following query: $q = "SELECT password FROM members INNER JOIN username ON members.user_id = username.user_id WHERE user_name = '$un' AND password = SHA1('password') "; Basically, you're telling MySQL to make a hash for the string "password"; as in, not the user's password, but always the string "password". That is why it's always the same, as far as I can tell.

Well, it looks like at this point, Larry will resolve the issue for you, but in general, I would do the following: 1) Add an if statement in your script to check whether the user of the profile being viewed is equal to the currently logged in user. Within the if statement, I'd add a link to a separate script for uploading an avatar image. 2) From the image upload script, I'd check one more time to make sure that the logged in user is in fact the same user. After testing that, I'd display a basic file upload form and more or less run the script the way Larry recommends. By doing that, you can more or less use Larry's script as is, and just link to that script when appropriate.

Larry's right, Shivani. You might want to rethink things a bit before attempting Ajax. Actually, it's best to create a page without Ajax first, and then add an Ajax layer on top of that, so that in the event that the user's browser does not support Ajax, they can still use your site the traditional way. With that said, I'll try and get you started by pointing you in the right direction. Note that most of this information is in Larry's book as well (although I don't have the book in front of me to confirm that). Also, I'm not sure why you're including the jQuery library. You can use it to "ease" the process of using Ajax, but it's not required. For the example below, let's assume that you've written the function for creating an Ajax object just like Larry recommends. HTML file ... <body> <button id="addFriend">Add Friend</button> <script type="text/javascript"> var oAjax = getXMLHttpRequestObject(); var oAddFriend = document.getElementById('addFriend'); oAddFriend.onclick = function() { oAjax.open('POST','add.php'); var sPOSTInfo = 'sFriendName=' + the-friend's-name-which-you-get-from-a-form-etc; // You need to URL encode the actual name string, but I forget the JS function name. // You also need to send the proper header when posting data, but I forget the name. Check Larry's book. oAjax.send(sPOSTInfo); oAjax.onreadystatechange = function() { // You want to test the state of the Ajax object and the HTTP return code, but I forget the exact property names. Please check Larry's book. // Once you've passed the required tests, receive the echoed message from add.php, and display it on the screen to indicate whether the friend was added or not. alert(oAjax.responseText); // You could also use the innerHTML property of a div, etc. to spit the message out to a particular location on the screen. }; }; </script> </body> ... add.php <?php // Receive the friend's name from the posted value. // Perform any necessary validation. // Insert the name into the database. // Echo back a message indicating whether everything is okay or not. ?> I know there's a lot of pseudo code there, but hopefully that helps.

After looking at your scripts more closely, I honestly do not know what's going on and what you want to accomplish. If you don't mind, please explain exactly what you want, and we can help you through this. If you just want to make it possible to upload an avatar, I really don't think you need to check the user ID and all that. Essentially, I'm not sure why you can't just use the first script, and slightly modify it to your needs. (By the way, your form in the first script is missing an end tag. I'm surprised that's not causing syntax errors.) Anyway, please tell us exactly what you want, and we can help.