21
edits
AniDB:AJAX development: Difference between revisions
Jump to navigation
Jump to search
no edit summary
Fahrenheit (talk | contribs) m (→Forum) |
No edit summary |
||
| Line 64: | Line 64: | ||
I'm missing the rar's from the mails, i can't upload stuff now, will upload them later. [[User:Fahrenheit|fahrenheit]] | I'm missing the rar's from the mails, i can't upload stuff now, will upload them later. [[User:Fahrenheit|fahrenheit]] | ||
=== Some more updates === | |||
I've done just a little more but am still holding onto it. | |||
Basically, the language codes are now decoded properly using xml's from ISO sources. Whatever the language code is, be it 2 letters/3 letters etc, and whatever locale, as long as it follows the xx, xx_XX or xx-XX format, it will get decoded into language (+Locale if available). I found that the xml file i used earlier only contains language, so it cannot decode langcodes like pt_BR : Portuguese (Brazil) properly. Now I linked in codes from ISO-639 (language) and ISO-3166 (country) so theoretically, it can decode anything that have been seen before. | |||
To reach out to all people, I was dreaming up these channels (just for discussion): | |||
==== HTML ==== | |||
Needed to support ancient browsers. (including some safari and opera that doesn't do xslt). | |||
* Ups: Simplest to read. No magic there as server does everything. | |||
* Downs: Server does everything, which means that server has to dynamically compose every single page (due to personal settings) which I'd been informed making it difficult to exploit remote http caching. | |||
==== XSLT ==== | |||
* Ups: Server throws out the xml, which is also used for ajax. so theoretically, when we have ajax, xslt comes for free. the style sheet is static. meaning can be cached etc. The xml file is also largely static (no dynamism due to user settings. It only needs to change when anime data actually changes.) Also allows splitting of data into domain. e.g. the same basic anime xml used by all. files and member only data can be sent in another separate xml to be merged on client's end. XSLT is available on almost all modern browsers. | |||
* Downs: There are still some browsers that don't do xslt. Also, a little hard to debug (that's a developer's problem), coz the source cannot be seen (if you look at src of a xslt generated html page, you won't see the html. you'll see the xml) | |||
==== AJAX ==== | |||
This is supposedly the real workhorse. Unlike opening a XSLT-transformed XML (which does a one time translation), an AJAX client will be a constant webpage that dynamically updates its parts on receipt of new data. E.g. if the user opens another anime, the ajax page will just request the required xmls and update itself. The modern pattern is to implement XSLT/JST into it's components. e.g. say I have a div set to contain anime episodes data. After retrieving the xml, instead of doing the traditional parse by javascript and manually add in stuff, the modern way is to declare a template before hand (potentially stored statically as a separate file) and use a general translater engine to merge the xml/xsl. makes client development a breeze, not to mention achieving component reuse (the xsl can be used in other pages too!) | |||
* Ups: Rich web experience. due to partitioning of xml data, potentially a large portion can be more static and cacheable. meaning server only have to serve the differences. E.g. the server may serve the same anime and episode info to all people, but may send a per-user xml which contains settings, preferences and mylist stuff. Lighten server load even further? potentially allow even more user customization like the skinning system (server tells client which skin file you use, which can be set by you), coz now, you can change the entire layout of the page by setting a different xslt/jst file sets?? | |||
* Downs: requires javascript. heavier on client end (but better client than server, imo). Have to be made more robust coz there may be higher chances of computer amateurs messing stuff up on their client end (as compared to server-spoon-fed html) | |||
==== AJAX ++ (javeline) ==== | |||
This is the future. And it is already here. I've already highlighted the link in my mail to Fahrenheit (www.ajax.org). It is a complete javascript-only, cross-browser development than can do most things that your typical desktop app can do.... windows, lists, trees. you name it, it has it. What makes it impressive is the ease with which it can be used. cross-browser means that no need to deal with differences in browsers directly. It really takes a lot off the mind of the developer in tinkering with javascript hacks to makes things work and allow more energy to be channeled into the important parts : Design. What's more is that the platform is being developed/maintained continuously, so we get "upgrades" automatically when time passes without having to sink in extra manpower to keep things shiny. | |||
* Ups: everything I've mentioned above. did I mention cross-browser? | |||
* Downs: supposedly even more demanding on browser. But from my testings on a typical 1.8 GHz AMD (single-cpu) using firefox 2, it seems to be still very light on cpu. | |||
Sphere | |||
== Comments, propositions and whatever else == | == Comments, propositions and whatever else == | ||