Adam

It shouldn't if it is declared outside the function first. That's true for Javascript, but not PHP. To make it work the way you are saying, you'd have to use g*****. Ahhhhhhh! You said the G word!!

Ah, that explains it then. Yeah if you call on(), on the DIV or other element that wraps around the auto-complete content you shall be laughing.

What xyph's version does is around the same as what jQuery will do internally. If you're already using jQuery there's no sense in doing it the manual way. What do you mean by "should be able to pull out the information I need anyways"? Edit Forgot to mention, it works for me. What browser are you using?

How is the HTML pulled into the page? Sounds like at DOM ready the elements don't exist still. ---- Worth reading if you want to understand why it's inefficient: live() is a work-around for binding events to elements that haven't been defined yet - e.g. elements that will be pulled in via AJAX later, but still need the event behaviours bound to them when they are. This is done by attaching all the 'live' events to the document object, and checking all of the selectors every time an event bubbles up. Given the events have to travel so far up the DOM tree, this also introduces issues with propagation and possibly noticeable delays before an event is triggered. So basically, seemingly unrelated events will be bubbling up and firing off these live event checks all over the place in an unexpected order. Things will quickly slow down with a lot of them, especially in older browsers. Don't get me wrong, in modern browsers the impact probably wouldn't be noticeable, but it's just being wasteful for no reason. jQuery also provides delegate() though, which allows you to attach these 'live events' to an element much further down in the tree, instead of the document root, that will always exist. This is much more efficient because events only have to bubble as far as the container element before the event is handled, and the event will always be relating to a child of the container element -- it's much more precise. All this said, live() and delegate() have now been deprecated as of version 1.7 and replaced with on(), which forces you to define live events in a delegate() style way. Just don't bind them on the document as that's all that live() does. i.e. these do virtually the same thing: $('#child').live('click', function() {}); $(document).on('click', '#child', function() {}); Bad! So do these, but this is the right way of doing it: $('#parent').delegate('#child', 'click', function() {}); $('#parent').on('click', '#child', function() {});

Drop the use of "live" though. It's awfully inefficient. You might also want to be more specific about the parent, given future changes to the mark-up could have unexpected results!

A quick validation check on the test file found errors. I'm guessing XMLReader is stopping when it hits that.

I completely see the need for standards in code. At what point though does it stop being to help productivity and just get plain picky?

.. If you're not using jQuery, you need to call removeChild on the parent node of the element you want to remove. For example, assume we have the following HTML: <div id="players"> <div id="player50"> John Smith </div> </div> (I've prefixed the ID with "player" by the way, because an ID is technically required to start with a letter.) Now we can remove it with the following code: var player = document.getElementById('player50'); player.parentNode.removeChild(player); That will completely remove the player element from the DOM tree.

You can't run a select query directly using JavaScript. Although you can use AJAX, which allows you to send a request in the background to a PHP script to get the results. If you're dealing with a relatively small amount of data though, it might make sense to just to echo the data into a JS variable to start with: <script type="text/javascript"> var data = <?php echo json_encode($array) ?>; </script>

That's what I've been saying to do? Only use push state if their browser supports it, otherwise just do everything as normal.

Ha erm.. older browsers? I would just download a few VMs to recreate the main environments you want to test.

Pushing an array into a parent array? Could you post the code? Seg faults can sometimes be tricky to debug, how have you narrowed it down exactly? Also some information on your machine could be useful; OS, PHP version, extensions installed, etc.

Ok, I will assume it's awesome then and blame you all if not.

By that I mean the actual error message PHP gives you.

The error might be useful?

Seems like there's a hole in the job market for tutors that actually know what they're doing

Don't think of it as fallbacks. Just write your site normally, then add some JS that will takeover the links/forms and alter the normal behaviour. Just be sure to detect if their browser supports push state first, so you're not hijacking links and then not updating the URL. You could implement this as a nice, clean object. Call it "Page" for example. It would handle the generic loading of URLs through POST or GET requests (i.e. form submissions or just requesting a URL), and loading into the DOM. You could also add a method that allows you to define "page load behaviours", so as each page is loaded you loop through a set of callbacks that re-apply click binds and such -- this would probably be more efficient than using live() or on(), and would also keep the generic page logic separate from the individual, page specific behaviours. You could implement it really nice, just try and keep away from lumping everything into one file and it all getting chaotic. Try and keep the logic separate, otherwise it will become harder and harder to maintain.

I don't think there's a rule you just didn't break I've felt that blow. A lot of assignments I've done in the past were VB, I hate that ?$%?@$ language!! Some people love it?

I think it's a good idea to put in fall backs. By "hijacking", I meant write the site as normal. Normal links, normal forms, etc. Then write some JS to literally hijack every link and form within the page to use your push state handle instead of the default action.

Okay, okay. I don't think that was quite what jesirose was meaning. Nor do I think the OP intentionally didn't declare the document as HTML5. Perhaps inform him that to use the "number" type, you must technically declare the document as HTML5? Even if older browsers default to text type. Then perhaps explain what a document type is, given he's not using any and probably is just using something he saw somewhere? HTML5, whether a draft or not, is relatively widely used. Calling it "not a real thing" is insane, and discouraging someone from using I would say is wrong.

Why do you think you access it through location.hash, or "hash bangs" for the URLs with "#!" in them? I was only pulling your tail anyway, I'm not fussed. Call it an obtuse pencil sharpener if you want

Chrome is now the most used browser, which updates automatically, so you could assume that the majority of users on the internet now have decent HTML5 support. Personally I would implement state, but hijack links/forms and provide non-JS/HTML5 fall-backs, instead of implementing it as the default action. The hardest part is getting your head around the state API, adding the fall back is easy. Although there's plug-ins and scripts around that make using the state API a doddle!

Hey up guys. A friend of mine is looking for something along the lines of what SocialEngine offers. Does anyone have any experience / reviews / alternative recommendations? The idea of it being more like software you install, as opposed to a PHP framework is the key. Thanks Adam

In real English # = "hash"

Sounds like you need to look into "responsive CSS".