Plus, the data transmitted using ajax may not even be XML. These days, JSON is more common. Or ready-to-use HTML fragments might be transmitted as well.
Plus, the data transmitted using ajax may not even be XML. These days, JSON is more common. Or ready-to-use HTML fragments might be transmitted as well.
Yep. I can only think of one site/application that actually pushes XML around in its AJAX requests: MS Dynamics CRM, and presumably the upcoming GP web client. But, there are reasons it's sensible to use SOAP services there. For most applications it's more sensible to use JSON or HTML.
I prefer serving up JSON these days for AJAX requests/responses, as it's a breeze to work with in PHP, and 99% of the time I don't have any need for whatever XML might bring to the plate that cannot easily be handled by a JSON structure.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
I love the HTML5 doctype. Much easier to remember when typing out a page by hand than having to insert a boilerplate for one of the other doctypes.
----------------------------------------------------------------------------------------------
WYSIWYG editors will never beat my hand written code!!!! Learn to do it in notepad and learn how to actually control your website! Current Project http://www.jmcanineservices.com
Yes, a few. One was a page used for updating the team information for a fantasy basketball league--it was XHTML+SVG, as it helped arrange the map.
Well, what prevents you from doing the same with the HTML5 doctype?
Originally Posted by NogDog
I prefer serving up JSON these days for AJAX requests/responses, as it's a breeze to work with in PHP, and 99% of the time I don't have any need for whatever XML might bring to the plate that cannot easily be handled by a JSON structure.
Object typing seems a bit clumsy to me with JSON -- not to mention, there isn't a standard way to do it. JSON.stringify() certainly doesn't perserve object type in any way. In many cases, x != JSON.parse(JSON.stringify(x));
And this can be sovled to some extent either by customizing your stringify and parse methods, or by JSONP at the expense of security. But, XML provides a standard way to identify object types. You may still have to write some custom code to serialize and deserialize an object; but if you're sharing that object with another application (or developer), which is the real power of XML, you don't have to worry much about application security or communicating any custom mechanism for object serialization and deserialization: it's all standard, almost every language on the planet has native(ish) methods for dealing with XML in a sensible way.
Also bear in mind, some IDE's (at least one that I can think of), can completely hide the details for you. Visual Studio allows you to create SOAP services as if they're just public methods. And it allows you to connect to SOAP services as if they're just objects with methods attached to them. You expose and access remote methods just like any other object.
But in many cases, JSON (or JSONP) are probably far better solutions than XML/SOAP.
Well, not that you shouldn't try to align your pages with the spec, but remember that validation is relatively meaningless. Most big sites don't even bother trying to adhere:
It's a pretty badge. Other than that, as long as the mainstream browsers can render your site, and you're not using any meaningless tags, you're good. That's really the goal -- to instruct you on using tags and structure that are meaningful to your audience. And validation serves as a guide, but it's not like browser vendors are going to stop rendering pages or supporting tags b/c the validator thinks they're wrong.
Reply With Quote
Originally Posted by Mr Initial Man
Bookmarks