Adam

I can't recommend any as I haven't used free hosting for quite a while. I guess give the first result a go, 000webhost.com? Can always try a different one if it doesn't work out.

There's plenty of hosts around that provide free hosting with PHP. As for that code, just delete it. Ignoring the many issues with it, JavaScript should never be used like that

There's also Github, which has plenty of open-source projects seeking contribution. It's also a good way to meet other developers and organisations, as well as gaining varied experience.

Haha! Good JOKE!

I'm guessing some might use nano too ... *shudders*

Perhaps you could formally suggest a better approach to the current situation? They must just be thinking "not broke, don't fix it" not realising how much better it could be. Can't you mount the network server locally and access using your preferred editor/IDE?

What do you mean by 'refresh the current page' exactly? load() only loads HTML from the server into the page, nothing is refreshed. What I suspect is happening is that when you're loading HTML into the page, your binds are no longer working, because the original elements have all been replaced or simply don't exist anymore. If that's the case then live() or on() is the right way to do it, though as mentioned before, the latter should be used if you have jQuery >= v1.7. The way they work is by instead of binding the event directly to the element, they use a wrapper element to bind to and wait for events to bubble up the DOM tree. Even if you haven't bound any event handlers to elements, they still emit events when interacted with; moused over, clicked, etc. That means you can change the contents of the wrapper as many times as you want, but the parent will remain listening for any events bubbling up. Once an event is received at the wrapper, jQuery compares the original target to the selectors it has registered and calls the appropriate handlers. The problem with live() compared to on() is that live() binds to the document, which means events have to bubble up potentially a lot further to reach the 'wrapper element' before being handled. That's obviously going to be marginally slower, but more importantly allows for a lot more interference from other events higher in the tree that could prevent the event travelling any further up. on() allows you to specify that parent element, so you can reduce the distance the event has to bubble up and so reduce interference from other events. In your case my guess is that the #decline button is within the pending_approvals.php response, and as you click decline on one item pending approval and the content is refreshed, the binds no longer work? If that's the case you need to use the DIV you're loading pending_approvals.php into as the parent element, and let the #decline.click event bubble up: $('#td1').on('click', '#decline', function() { // handle here });

The .on() and .live() APIs are not the same, so you'd need to show your code. Are you getting any errors though? If you are that will be far more useful!

You can't access the variables within a function like that. Going with your example, someFunction in JavaScript represents a callable function. You can call it as many times as you like, but it has no state -- no "context". The variables defined within it are essentially lost after each call, except from what you return. It is possible for functions to retain state after they've been called, in a sense, but you need to create a new instance of the function and store variables within the this context object. Plus the function itself never has state, it returns an instance of itself which actually contains the state. For example: function foo() { this.bar = 'baz'; } var instance = new foo(); console.log(instance.bar); // outputs: bazAs you can see, new foo() returns an instance of itself we store in the instance variable, which we're then able to access the properties of.

Why when you're using jQuery don't you just use the browser object?

Also, you do realise jQuery is JavaScript right? jQuery is a JavaScript library.

This doesn't sound like a great reason to me. Why are you trying to fix something that's not broken? Not to mention .live() is deprecated as of v1.7; if you're upgrading I would upgrade straight to v1.9 and use .on() instead. As for the code, I can't see any issues with it. What errors are you getting in dev tools?

You would need to resolve the video variable to your actual video element, perhaps using getElementById(), but apart from that it's relatively straight-forward. You bind a callback to the 'ended' event, and when the video ends your callback is called. Assuming that snippet is correct, it looks as though the callback is bound to the video object, so you can use this to refer to your video element.

Can you show the HTML you're using that with?

Hmm I don't see any need for nth-child? How are you thinking of using it? Put simply, AJAX allows you to script requests to the server in the background without reloading the page. Back in the day this was invented for requesting XML, which is where the name comes from, but these days it's quite often JSON or simply HTML that's returned instead. The request is made with JavaScript using the 'XMLHttpRequest' API, however it's not particularly user-friendly and there's a few cross-browser quirks you have to cater for. JavaScript libraries like jQuery wrap XMLHttpRequest and provide a much nicer API, and take care of all the cross-browser crap for you. Underneath it's all the same though.

No worries. You may need to use .parents() instead of .parent(), if the wrapper element you're trying to select is not the direct parent.

Ah, I see what you mean. Well for one don't access the corresponding elements via ID, given IDs are unique. I would give them a class and find them relative to a parent element wrapping them. For example: <div class="wrapper"> <select class="a"></select> <select class="b"></select> </div> <div class="wrapper"> <select class="a"></select> <select class="b"></select> </div> <script> $('select.a').change(function() { // Select .b relative to the current .wrapper parent $(this).parent('.wrapper').find('select.b'); }); </script>Does that make sense?

What do you mean by "increment the number of variables in my form" ?

Can't see anything of note. Can you add in some console.log calls to debug where the break is happening?

Not sure I understand what you're asking here. You're passing the option names and values into the function?

Alternatively if you were to only bindAllTheThings() when the browser is NOT IE7 or less, you could still bind certain functionality and not others: $(function() { var isIe7 = ($.browser.msie && parseInt($.browser.version) <= 7) ? true : false; if (!isIe7) { bindSomeThings(); } bindRestOfThings(); });

You could use IE conditionals to only include the script for IE8+, but I would build the logic into the JS, not the HTML. Using jQuery you have access to $.browser which makes it easy. In the document ready function or however your code is initialised, just add a return statement when the browser is IE7 (or less I'm guessing too?) $(function() { if ($.browser.msie && parseInt($.browser.version) <= 7) { return; } bindAllTheThings(); });

Assuming you mean 'experience', you would list references that proves you held x position for y amount of time. The company will then check your references back-up your claim once you start working for them. If you were lying, I'm not entirely sure what would happen but you would certainly get fired and maybe taken to court. I would imagine if you didn't have the experience they'd notice pretty quickly though and you'd probably loose the job anyway, maybe before the references even responded. Not sure what they would do if you were amazing at the job and you'd lied though?

I imagine most people don't look to their hosting company to advise them of what programming language to use, but look for a hosting company that provides what they need. That's probably why GoDaddy lists all the languages you can use, and not which you should be using. Also just to add, PHP extensions don't introduce new constructs into the language unlike Perl. Everything is included within the core, extensions just add new classes and functions. Most hosting companies provide the common ones though.

I wouldn't say every job is time critical. Also depends what kind of clients you're dealing with, I took the OP to mean a site built from scratch, not integrating with an existing system. That's a whole new kettle of fish. You're right though, clients can sting developers with that kind of thing, just as much as the developer could sting the client.