Idea: SoD-DB.com aka SoD's "WoWhead.com"

Why generate XML then have javascript parse it then display it. Why not just have it export a native javascript serialized object? I'm thinkin there's gunna be a lil less overhead. Plus from what I have read, JSON parsing is actually quite a bit faster than XML.

(but again, we dont need to parse it since javascript will be reading the object in and displaying the data)
 
Dynak said:
Why generate XML then have javascript parse it then display it. Why not just have it export a native javascript serialized object? I'm thinkin there's gunna be a lil less overhead. Plus from what I have read, JSON parsing is actually quite a bit faster than XML.

(but again, we dont need to parse it since javascript will be reading the object in and displaying the data)
Click to expand...
Not saying JSON is worse then xml they both have strengths and weaknesses.

You are correct on the fact that JSON parses faster, but it is still matters of milliseconds for either one, nothing which is really noticed by the end user.

I beleive XML is also supported by most browsers and runs quite fast if you use the browser itself to read the data, ive never done it this way always used 3rd party tools but thats an option too.

Also i've read somewere that json inherently has a security flaw since the eval statement will execute any code it receives. Something which is impossible to do with xml (Given its only run on client side theres probably not much that can be done with it though).

It's the lack of any real benefit over XML that has me a little confused as to why i should switch, I mean i can do it just the same with xml or json. JSON has the advantage of being able to be interpreted directly by javascript but XML is much easier then json to interpret by most other languages. Im left to wonder if its more efficient to write two types of interfaces or just one that works every were. Might be different in the future though when json gets a firmer establishment.

Also as a side note, XML can be searched JSON cant without making the search function yourself.
 
You can search JSON the same way you'd search any object.

Also, for security, browsers wont let you "ajax" to a site outside of your current viewing domain. So you really cant hijack by redirecting to a external site to inject bad code into eval(). TBH it really depends on what you are doing, if you have full control over the site and want a quick and easy way to take for instance a php object and dump it into javascript for ajaxness - then why not go json? However, if your building a site that pulls data feeds from multiple sites using different technologies (coldfusion/asp/php/flash action scripting..etc) then I'd probably vote for XML as well (but I dunno, json support is getting to be pretty big!).
 
Datass550.jpg
 
Dynak said:
Ajax is way more than just return search as you type, basically its asynchronous calls back to the server to retrieve/update information w/ out refreshing the page.

I am actually looking into coding a plugin for our wiki that will utilize mediawiki's api. Basically it will retrieve page content in json format that will be request by a javascript call when you mouse over an item link. The data it retrieve will then be displayed in a tooltip shoewing you item stats/etc. It will require a special tag be added to the wiki but it I'm still modifying the necessary code.
Click to expand...

I did something similar to this over at: http://www.wmich.edu/evalctr/
Except I did it server side. Any time a page was updated, it would parse the page, and replace any terms it found from the wiki db with a link/tooltip. It also ran on a weekly basis and updated any terms that were updated in the wiki. Very kludgy, but it was one my first real-world programming experiences.
 
You must log in or register to reply here.
Back
Top Bottom