KevinM1

Why not? AJAX, at it's core, is essentially the client script invoking the server side script's methods/functions and displaying/manipulating the results without a page refresh. There's no reason not to have a design that can do nearly identical if a user causes the invocation instead. AJAX shouldn't be a requirement of your site/CMS. You should design it to work properly without JavaScript first, then add it on top of that proven foundation.

I actually have no problem with more nuke plants. I'm more weary with oil and coal as, like John mentioned, the vast majority of our means of transportation cannot run on coal, and both are finite material (so is nuclear fuel, but its consumption rate is far less than fossil fuels). I still have big hopes for solar. Given the sheer amount of energy that comes from the sun, and the tiny little amount that we can actually harness, there's a ton of potential still left untapped. It's also the renewable source that will require the least amount of cultural change. Solar already powers homes, automobiles, and other electronics. It doesn't require anything but a clear day. If we can figure out a way to tap into the invisible spectrum, even that wouldn't be necessary.

IMO, whether or not man made global warming/climate change is a crisis in waiting, not as bad as we're led to believe, or even real is a moot point. There's no good reason not to try curbing emissions, reducing pollutants that enter the air and our water supply, and attempt to gain energy independence from a bunch of pissed off Middle Eastern people who have no qualms about killing us. If climate change IS a boogyman, will it really matter in the long run if we increase efficiency and get out of the Middle East? Indeed, given human nature, a crisis like this - real or fabricated - is what we tend to need to get moving on long term goals. A cause to rally around which will give us a swift kick in our complacency.

Also, ironically, 'misspelt' isn't a word. You're looking for 'mis-spelled'.

Yeah, this definitely sounds like a design issue. OP, mind giving us a more clear example (or, better yet, your code thus far) illustrating what you're trying to do?

function checkCreditCard(cardNum) { var regEx = /^\d{16}$/; if (!cardNum.match(regEx)) { alert("Credit card number must contain 16 digits"); return false; } else { return true; } } Note that this assumes that the proper pattern for cardNum is simply a string of 16 digits without hyphens or spaces.

I think that taking breaks is critical when playing MMOs. Like I said in another thread, I've played WoW since launch. I've only very recently got to the WotLK portion of the game (intro zones). My main is only level 72. I find it so much more rewarding when I subscribe and play for a month or so, then freeze my account when I get bored. It keeps things from getting too stale. In fact, I just froze my account again for that very reason, and probably won't start up again until Cataclysm comes out.

I don't think that MT is mad. Also, if my app is running slowly, looking at how my output was interpolating variables would be one of the last steps I'd take, simply because there are other things that would be the likely source of the slowdown. Not saying that you wouldn't, either, it's just that there's a common meme with some users on here where they think that code optimization (which shouldn't be a priority until the late stages of a project) consists simply of fiddling around with how output strings are quoted and concatenated because some book or tutorial mentions that one way of doing it is 'faster' (hundredth's of a second, if that) than another. All while they have nested loops running amok everywhere. Again, not lumping you, specifically, in that group. Just figured I'd comment on a general trend I've seen in order to help curb things in the right direction.

To be safe, you should put your $_GET variable in curly braces to ensure it's handled correctly, like so: $url = "http://www.site.com/soccer/{$_GET['league']}";

Did you look at any of the links? Processing JSON returned by the server essentially boils down to using either eval() (not recommended - see below) or JSON.parse to transform the string of the response text into an object. A quick example using jQuery: ajaxtest.html: <!DOCTYPE html> <html> <head> <title>Ajax Test</title> <script type="text/javascript" src="js/jquery-1.3.2.min.js"></script> <script type="text/javascript"> $(document).ready(function() { $.post("quickajax.php", {action: "red"}, function(data) { var response = JSON.parse(data); //var response = eval('(' + data + ')'); $("#box1").html(response.id + " : " + response.cost); }); }); </script> <style type="text/css"> #box1 { border: 1px solid red; } </style> </head> <body> <div id="intro"> Trying a simple server request.... </div> <div id="box1"></div> </body> </html> The commented out line works, and is there to illustrate the other (dangerous) way to get at the object. My PHP is simply: quickajax.php: $action = $_POST['action']; if ($action == 'red') { echo '{"id" : "Red", "cost" : "2.49"}'; } Hardly thrilling. Again, after the JSON is parsed/eval'ed, you can treat it like any other JavaScript object. This means you can dynamically calculate one's remaining money (via response.cost, in my example) and stuff the result into any HTML element you want. Just be sure you use correct JSON syntax (http://json.org/index.html) when building your response text. Also, I'd avoid using eval() for this. Eval() will attempt to evaluate anything as executable JavaScript. That could lead to security headaches. JSON.parse will only parse (surprisingly) incoming JSON, and throw an exception otherwise.

http://lmgtfy.com/?q=ajax+json+response

an explanation would of been better because honestly you don't need classes at all. Heck you don't need these high level languages. You could use assembly. Procedural code may be faster than OO code in terms of cycles, depending on how objects are created/disposed behind the scenes. That said, OO code tends to make writing and maintaining code much faster. By its nature, OO code is modular. Meaning, a change in one portion of the system won't likely necessitate a change in another portion. This modularity also promotes code reuse. Instead of copy-and-pasting individual lines of code from one project that may work in another, you can transport entire subsystems without much effort. These two benefits reduce the time it takes to actually write useful code. It also makes site maintenance much easier.

What does that have to do with anything? The response text comes from the server side script. You can have it return some JSON, then have the JavaScript portion retrieve the new money value from that and dynamically put it where it needs to be via DOM manipulation.

Instead of two scripts, combine them. <script type="text/javascript"> // When the document loads do everything inside here ... $(document).ready(function(){ // When a link is clicked $("a.tab").click(function () { // switch all tabs off $(".active").removeClass("active"); // switch this tab on $(this).addClass("active"); // slide all content up $(".content").slideUp(); // slide this content up var content_show = $(this).attr("title"); $("#"+content_show).slideDown(); }); $('a[rel*=facebox]').facebox({ loading_image : 'loading.gif', close_image : 'closelabel.gif' }) }); </script> You have two things going on here: 1. You tie some actions to the click event of an element 2. You tie some actions to the facebox As you can see, both of these can be done in the same script. And, again, since there's only one document - the web page itself - you can only have one $(document).ready() function anyway.

Feel free to make a new thread if you have questions.

Why can't you return the amount of money to be subtracted from the user in the response text?

Think about what you're writing: When the document is ready, the code in the first script tag is what I want to be run. When the document is ready, the code in the second script tag is what I want to be run. Notice there's no 'and' or 'or' between those two statements. You're overwriting what you want to be done with the second bit of script instead of combining the two. There's only one document in play here - your site. Thus, it can only be readied once. Combine your code.

Not safe. First, and this is only because it's a pet peeve of mine, JavaScript != Java. The two have nothing to do with each other. JavaScript is a version of ECMAScript, developed by Netscape, and later, Mozilla. The 'Java' in its name was a marketing decision made when the actual Java language was hyped to be the best thing ever in the mid-to-late 90's. Java is a full-fledged OOP programming language that runs on a virtual machine. It was developed by Sun Microsystems. So, with that out of the way... You need server side validation. Why? Because JavaScript can be turned off in the browser. That's as safe as guarding Fort Knox with bad language. JavaScript validation should only be viewed as a courtesy to your users, as it facilitates a more interactive experience. Server side validation is a must. Also, I suggest passing your values by post rather than get. While nothing is stopping a malicious person from making their own form and posting values from it to your script, at least they won't be tweaking values right in the address bar.

how does that relate to your topic tittle "Re: How do I use a global footer..?" Can't you use a footer include? yea but when my exit get's run it aint including anymore therefore it wont show? lol Write better error handling that doesn't rely on exit or die? We have a blog post on it: http://www.phpfreaks.com/blog/or-die-must-die

You should probably look up what output buffering means....

Well, with forms, you need to supply them an action - a script which will process the data entered in the form. Given what you want to do, the action should be the same PHP file that contains your HTML form. It can be referenced like so: <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post"> In order to obtain the values entered in the form, you'll need to use the correct superglobal array. These arrays are mapped to the different form methods, so there's a $_POST[] array and $_GET[] array. Example: <input type="text" name="name" /> Can be obtained with: $_POST['name']; Aside from that, since the form is essentially posting to itself, you should structure your page so the form handling (the PHP that processes the form data) occurs first, followed by the HTML.

That w3schools quote is a bit misleading, and a good example of why you shouldn't rely on them to learn anything other than some basic syntax. JavaScript validation serves one main purpose - to give the user better, more immediate feedback when they supply data to a website. It should never be considered the last line of defense as JavaScript can be turned off in the browser, rendering such validation completely worthless. Those with malicious intent know this, and will definitely try to exploit this innate weakness in JavaScript. Moreover, there are still non-threatening users who surf with JavaScript disabled for a variety of reasons. Server side validation should always be done because of this. And, since server side validation should always be done regardless of whether or not JavaScript is involved, there's no real server load benefit. The best way to do it is to use both simultaneously, using the same filtering rules on both sides to ensure nothing falls through the cracks. That said, is there anything specific you need help on? Have you written any code?

Interesting topic... I think that there is a bit of an air of superiority with myself and my fellow badged members. I also think it's earned. We know our stuff. We've proven it to the powers that be. After all, badges are given out based on merit, and that decision is made by more than one person. I think the sudden influx of four new Gurus shows that we value intelligent, helpful members who have been consistent in the quality of help they provide. Moreover, it shows that the overall quality of the board is improving. On the other side of the coin, we don't suffer fools very well. I think that all of us are more than willing to help those struggling to learn PHP - if we weren't, why else would we volunteer our time? Our help is predicated on a few things: 1. People obey the rules. It's not hard to do. The rules are clearly visible to all - there's a link to them at the top of the page and many of us also have the same link in our signatures. Being ignorant of them when a dispute comes up isn't much of an excuse given their easy access. They're also easy to follow, as the majority can be distilled down to Wil Wheaton's Law - Don't Be A Dick. 2. People actually attempt to work at the problem they're having. We don't mind helping people so long as they're attempting to do some work on their end. They cannot expect to drop a problem in our laps, say "solve it," and get a finished result. We have a freelance section for that sort of thing. 3. They clearly describe their problem. We're not telepathic. What is the problem? What should be the correct behavior? What have you tried? 4. They shouldn't expect a badged member of the team to answer their questions. We're volunteers and there are hundreds - to - thousands of posts to read. We can't get to them all. Amazingly, all of this is mentioned in the rules. I view getting snarky at those that can't follow the rules as a deterrent. I know it's not polite, but if it can convince those insisting they're more important than the rest of the community to ultimately leave, it's worth it. Given the value of this forum, I'd like to at least keep the signal-to-noise ratio where it is.

Just noticed a typo - remove the ()'s from the line: window.onload = showtable(); So it reads as: window.onload = showtable; EDIT: why is it a typo? onload is an event - event handlers are assigned to the event in question...the ()'s indicate invocation, which doesn't make sense in that context.