Open main menu


no edit summary
I've seen the basic stuff of what's going on. I've also tried to tweak the xml XML specification a little to single out those that are general (to all of anime community) and those that are AniDB specific (I use a namespace idea so that AniDB stuff like ids, ratings etc . are clearly marked).
Also tried throwing in a more general resource tag so that anything can be referenced there. (one example is the anime's main image, any weblinks to external databases, official sites, additional links to images and videos etc.)
As I was reading up stuff, it occured occurred to me that if we had some ajax-ready xml apiXML API, it could be far more useful than just for ajaxAjax.Using XSLT, what was traditionally done on server (transforming data to html) can be pushed to the client. If the data is carefully segmented into largely static ones (like basic anime info that doesn't update a lot) and more dynamic ones (like episodes and files), there is potential gain if inter-server caching can be exploited (since the xsl XSL does not change at all, and the xmls XMLs can be chopped up such that some parts do not need to be updated that often and can be locally/isp ISP cached).
The only shortcoming is that xsl XSL is a pure declarative language. So to achive achieve some dynamic formatting (e.g. say if you want every odd row in a table to have different style), may need runtime javascriptJavaScript.
There are some quirks though... e.g. I can't see the generated html source anymoreany more. when I look at source, I see the xml XML only. dunno whether that's good or bad atmATM. [''[[User:Rar|Rar]]-You're missing the fact the transform doesn't have to run in the browser. [ libxslt] has py bindings, try that. Or just CTRL+A/View Selection Source in foxy.'']
one nice thing about this is that the AJAX parts can be built directly on the xml XML so one common data format may serve the various clients (raw html, xslt, full ajax Ajax web app (see the javeline demo link I placed in the readme file))
anyway, attached a sample of what I was trying out. it consists of only a xsl XSL and xml XML file. Just open the xml XML file in your browser and the xsl XSL will be automatically applied. If you think this is interesting enough to the rest of the mods (regardless of whether it needs to be interested, I just thought that if they did not know yet, at least they should know that this is possible?)
btwBTW, from the looks of things and the political reason you mentioned for not supporting ajaxAjax, I really don't know where to go start or where to go from here. If the general mood is to stick to what we have, does that mean that you and I are just working towards a closed door?
=== Mail 2 ===
--fixed the odd-even row formatting. now the formatting should be correct regardless of how many rows are in the info.
--episode list (no files yet) added. sorted on type and episode number. Episode title is chosen by <defaultlang>...</defaultlang> in the config part of xmlXML. if the language is not found, it will take any language. If no title is found, it will display "unknown title"
--pasted back in the menu (guest access).
--all the links on page is based on, so any relative link still link correctly back to anidb AniDB site
--added another test data (a235.xml eh.. chosen for the large number of official languages)
I think I will take a break until there is feedback. xslt is just a middle ground, but it is probably the basis for future ajax Ajax development, as it totally separates the xmlXML's dependency on formatting. If you are still busy, perhaps I can bring this to the forum by creating an ajax Ajax development thread?
=== Forum ===
=== 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 XMLs 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 XML file i 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):
==== XSLT ====
* Ups: Server throws out the xml XML (no html at all), which is also used for ajaxAjax. so theoretically, when we have ajaxAjax, xslt comes for free. the style sheet is static. meaning can be cached etc. The xml 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 XML used by all. files and member only data can be sent in another separate xml 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. [''[[User:Rar|Rar]]-Name one?'']
[''[[User:fahrenheit|fahrenheit]] - I think rar tried something in these lines before'']
[''sphere - this is a link to a simple list of browsers that do support xslt natively, []. One thing to add is that the support here I'm talking about is NATIVE support. Even on a browser with no NATIVE support, though it is not possible to open xml XML natively and have the stylesheet kick it, it is possible to do XSLT within the AJAX environment through javascript JavaScript libraries, by manually loading the xml XML and xsl XSL and merging them using the provided apiAPI.'']
==== 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 Ajax page will just request the required xmls 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 xmlXML, instead of doing the traditional parse by javascript 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 xmlXML/xslXSL. makes client development a breeze, not to mention achieving component reuse (the xsl XSL can be used in other pages too!)
* Ups: Rich web experience. due to partitioning of xml XML data, potentially a large portion can be more static and cacheablecachable. meaning 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 XML which contains settings, preferences and mylist 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??
[''[[user:fahrenheit|fahrenheit]] - you can change the CSS stylesheet on the profile options'']
[''sphere - CSS stylesheet can only style the fixed DOM, with xslt/jst, the same xml XML can genereate generate totally different DOMs (which can be further style by individual CSS). But this remains just an option atmATM, since we're still emulating the original anime and it seems good enough that there seems to be little suggestions for some changes that are so radical that CSS alone is insufficient :)'']
* Downs: requires javascriptJavaScript. heavier on client end (but better client than server, imoIMO). 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) [''[[user:fahrenheit|fahrenheit]] - for the first part it can be impractical for large anime, for the second, can happen with server-spoon-fed html, we had some greasemonkey scrips scripts before, you can mess with anything that has a dom tree'']
[''sphere - for the first, I'll like to think for data of AniDB's size, it is still mostly ok as we at most deal with one anime at a time, but this is groundless until we can do some testing'']
==== AJAX ++ (javeline) ====
This is the future. And it is already here. I've already highlighted the link in my mail to Fahrenheit ( It is a complete javascriptJavaScript-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 JavaScript hacks to makes things work and allow more energy to be channeled channelled 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 tests on a typical 1.8 GHz AMD (single-cpuCPU) using firefox Firefox 2, it seems to be still very light on cpuCPU.[''[[User:Fahrenheit|Fahrenheit]] - It still seems to be a bit incomplete, looks nice, but i don't know if this could handle large amounts of data. Still the framework concept has already been bashed a couple of times on to my head, including but now limited to moochikit'']<br />[''sphere - I'm not sure about load tolerance too. This has to be tested if we ever moved there. What attracts me here isn't just the set of features (for which there are many libraries which can do very sophisticated stuff). Rather, it is the ease and intuitive way whereby a 'template' is declared. And these templates are potentially reusable by other people. e.g. From a single AJAX DOM, I could have one template that generates the basic anime info, another that generates the episode list. These two templates can be used on other pages as well to provide the exact view by linking in the template content which can be stored statically somewhere. The typical page designer just do things like 1. create a div, 2. load an xml XML and a compatibe xslcompatible XSL, 3. call some javascript JavaScript function to render the page. Similar to styles, these template files can be customized and 'shared' between users.'']
==== Multilingual support ====
[Sphere] Added this as afterthought. I tried fooling around with the basic anime info xslt and managed to add in translation time multilingual support. basically I created a very simple string table in another xml XML that specifies a language and a list of key-value pairs that denotes a key in some default language (english English in this case) and a translated value. This will convert all the static strings like menu items, field names etc . to the language specified in the config section of the xml XML if it can be found. If not, it will use the key as the original string.
Optionally, to save space by not using a long string as key, each entry in the string table could use the @id attribute instead, and references each string by a number. Personally, I find using strings easier as it makes the original xsl XSL more readable...
example of xml XML with string table (each language xml XML can have more than one string table each corresponding to a different language).
Can also potentially derive which language xml XML to use by filename... e.g., etc. So when AJAX kicks in, it can try to load the correct language file based on default language, or in the absense absence of the file, use back english English (which are embedded as keys in the xslXSL, so it does not need a separate language file)
Also, the skeleton of a language file can be automatically generated by parsing an xslt and search for '''<xsl:call-template name="getPresentString">''' and then parse the key, and the unique ones in a dummy language xml XML in the correct structure. This allows people to use the dummy xml XML to do translation easier.
I actually use <presentation> as the root of "language" file has it could potentially be expanded to point to a wider range of resources.. e.g. some images representing buttons with rendered text may need different version for different language, so they can potentially be embedded into the more appropriately named localization xml XML file as well.
==== Files available here ====
uploaded them here.
2 sample data (right click and "view source" to see the dummy xml XML data)
1. [] [] These 2 dummy data files has lots of titles defined (Some with same official titles get defined over several xml XML elements, but xslt collects them and display as one row)
2. [] This is another dummy data one shows the language file in action. I created my own "reverse-speak" (just reversed all words. LOL) I also defined some general online resources that are enumerable, searcheable searchable and filterable by xslt. The "image gallery test" below could be expanded to say only display images of chracterscharacters, or images of a particular character, or only screenshot images from the film etc.
3. [] This is the xsl XSL file.
4. [] This is the language file where I define the fake language
5. [] [] These 2 are the publicly avaialble xml available XML with language and country codes used to translate the language text (when you mouse over the country flags beside the official titles)
6. [] This example illustrates simple multilingual by setting japanese Japanese as default language. Notice that static strings (some are not done yet though) gets changed. Also, episode list automatically tries to list those titles of default language as the first title. Other AniDB code lists like category names etc . are not handled (coz I don't have the complete list ready) but can potentially be done so, such that if entries corresponding to specified default language is available, it can get loaded. (Do pardon any translation mistakes as I am not a native speaker)
== Comments, propositions and whatever else ==


MediaWiki spam blocked by CleanTalk.