1. Get back the response object, and then insert the data appropriately by making the xml dom object methods.
2. Get back the response object, and then create a whole bunch of html in a string and pass that into the innerHTML of some div element. This is still acceptable for me where I might have to consider the implications of browser-specific issues with dom method usage. The classic one I’ve found is when I have to write setAttribute(“class”, something) AND setAttribute(“className”, something) for it to work on IE and Firefox. If I just wrote a string and passed it to innerHTML, I can just write the html in it that would be more browser-friendly than the dom methods.
3. Get back the response object which itself has presentation logic that the client just passes to innerHTML of a UI element. Am I being snobbish or elitist to think that this is stupidness? Or maybe it’s the object-oriented programmer in me squirming to still maintain elements of object-oriented programming in a programming domain where you have to use a whole bunch of hacks to do anything that resembles good coding practices (which then nullifies the effort to bring about some order to the way we integrate html with back end systems). It’s not that I’m just being a purist in not wanting to receive presentation content directly from a service call that was meant to be a search or an action. It’s just that this approach seems to make programming more like taking a whole bunch of darts and flinging them at a dartboard and hoping that somehow they all stick in the right order in the right place. Debugging any problems becomes a nightmare. Not only that, whoever’s going to come to maintain this code after you leave is going to curse you for being an insensitive git.
Source: https://chanchal.wordpress.com/2008/06/13/how-do-you-do-basic-ajax/
No comments:
Post a Comment
If you have any doubts or questions, please let us know.