Details
Subscribe
Post Categories
Recent Articles
Display Settings
Translate
|
Crucial updates in OAT 2.4
Crucial updates in OAT 2.4
OAT version 2.4 was released recently. There are, of course, many updated things, but several of them really need attention.
First of all, our current core project, the RDF Browser. It is now greatly enhanced, which - in addition to its modular structure - allows really comfortable ways of exploring RDF data. I am adding new visualization tabs from time to time: we now have 8 of them. Newest tabs are Images (simply retrieves all image links from RDF and displays them) and Navigator. Navigator is in many ways similar to Browser, but there are no <a>++ lookups: instead, clicking on an URI changes current resource. If this URI is not dereferenced yet, it is first acquired (via sponger, of course).
I have also rewritten the DAV Browser basically from scratch. It is now easily extendable and displays additional information: file owner, group and permissions. When files are saved, one can also specify their permissions.
As reported in earlier post, JSON security is a popular topic now. I am glad that our support for this matter was finally included in a stable release, and not only in CVS builds.
One major change in 2.4 (which is not particularly visible, but important) is reorganization of core OAT components. The dependency handling and dynamic inclusion process was separated to bootstrap.js file; large monolithic OAT.Dom library was splitted into several smaller, standalone logical entities: OAT.Style, OAT.Dom and OAT.Event. Not only this brings more logic into function names, but also helps maintaining objects of reasonable size.
I spent lot of time optimizing the performance of SVG grapher component. The SVG speed is really an issue, because dragging a graph with hundred of nodes is just a pain. I believe I managed to reduce the JS overhead to minimum, so now the bottleneck should be only the actual SVG renderer.
Last but not least, the OAT.Tab component now allows 'undocking': this way, one can pull off a tab (by dragging) from its parent container, displaying contents in a window. This is a welcome addition specifically to RDF Browser, where one can now view multiple visualizations at the same time.
06/07/2007 06:58 GMT
|
Modified:
02/05/2008 08:40 GMT
|
OAT's versatility
OAT's versatility
If you haven't done already, visit the OAT Gallery - an OAT-based personal photogallery solution. I created this in my free time with goals different from any other OAT-based projects: no database, php-based, non-standard original layout & look. My sample installation is here.
As one can see, only few parts of OAT are actually used: only the OAT.AJAX library and Timeline widget. This is a nice demonstration of how multi-purpose and versatile OAT is.
05/04/2007 03:09 GMT
|
Modified:
02/05/2008 08:48 GMT
|
Data access: compare with IBM
Data access: compare with IBM
IBM has recently release their own JS-based DB connectivity API. Unfortunately, they are quite restricted in terms of DB choice and Data formats selection. Let me give you a quick comparison of OAT's Data access layer with IBM Database Connectivity for JavaScript: Feature | OAT - data access layer | IBM Database Connectivity for JS | Data sources
| SQL, RDF, XML, Web Services
| SQL | Platform | Independent (Client and Server)
| Windows XP* (Client and Server)
| Application server
| Any HTTP (WebDAV preferred)
| PHP 5 with PDO extension
| SQL databases
| ODBC, JDBC, OLEDB, ADO.NET, Virtuoso
| IBM DB2 | *Windows XP is mentioned in the Requierements page. However, one may safely assume that JS code (Client) will run on any plaform. Similarly, it is mentioned that other DB/OS combo might work by using other, PDO-compliant server.
04/20/2007 03:17 GMT
|
Modified:
02/05/2008 08:48 GMT
|
New script file: append or write?
New script file: append or write?
Following my last post about OAT's dynamic loading, I have to mention how is the script inclusion actually implemented. The task is easy: add a new script to already loaded HTML document. You have two basic options:
- document.getElementsByTagName("head")[0].appendChild()
- document.write()
OAT uses number one. Not only it is more aesthetic and native DOM approach, but it also works. Compare with Google Maps API or Yahoo Maps API: I created these two demopages (google, yahoo) which show how document.write() puts Firefox into endless loop. No, thanks. The same applies to Microsoft's Virtual Earth. The only correctly implemented mapping engine is OpenLayers.
Remark: of course, when used in classical way (in document's head during page load), these APIs work fine. I am talking about non-standard, delayed, inclusion.
Now one can ask why document.write() applied to loaded page freezes Firefox? Easily! First of all, this resets contents of whole page (so it gets blank); second, there is no document.close(), so page remains opened for writing forever. Pretty ugly stuff.
For your information, I have notified both Google and Yahoo developers about this, multiple times. Noone has ever bothered to respond!
04/11/2007 03:01 GMT
|
Modified:
02/05/2008 08:48 GMT
|
Toolkit size and dynamic loading
Toolkit size and dynamic loading
Let's have a quick look at OAT's size. The core set of JS files (excluding documentation, images, styles and bundled applications) has over 1.6MBytes (89 files total with build 20070406). Now that is some amount of data, I can almost hear people whispering "I am not going to include such big framework into my tiny application; my users are not sitting at 10+Mbit lines!" Well, this is completely misleading thinking, as you will soon see. OAT uses dynamic loading of libraries. So, in real life, the only file you *have* to include is loader.js. This one contains basic shared code and supplemental routines. Its size is cca 30kbytes (compare with prototype.js, weighing over 70kbytes). You can then specify which features you would like to use; OAT will create a dependency chain and include all needed files. Watch: <script type="text/javascript">
var featureList = ["grid","ajax2"];
</script>
<script type="text/javascript" src="oat/loader.js"></script>
This is a typical OAT setup. User wants to have Ajax functionality and Grid widget; the only manually included file is still loader.js. Now you may be wondering "What if I decide to include additional features *after* the page was loaded?" No problem for OAT, as you can see: var callback = function(){ alert("Pivot component is loaded and ready!"); } OAT.Loader.loadFeatures("pivot",callback);
04/07/2007 03:41 GMT
|
Modified:
02/05/2008 08:48 GMT
|
OAT and JS Hijacking
OAT and JS Hijacking
There has been some recent buzz regarding security issues of Web 2.0 sites. I decided to thoroughly study and analyze how this works, manifests and influences JS toolkits.
The best approach here is to study whitepaper located at http://comparitech.net/websecuritytools . One can find a typical attack scenario, some defense suggestions and security considerations. While the paper is (in my opinion) oversized, telling rather small amount of facts on large amount of pages, it contains some interesting information. Let me share how all this relates to OAT.
First of all, I must conclude that none of OAT-based apps is vulnerable to mentioned attacks, for two reasons:
- attacks are only appliable in JSON documents, fetched via GET method. Our OAT apps use XML format, requested with POST (via XML/A - SOAP).
- attacks are only appliable when security tokens (i.e. user name, password) are passed via browser cookie. This is not our case, since we pass these in POST request's body.
However, we might take into consideration the fact that OAT can be used for building different applications. So I added some low-level support for security countermeasures mentioned in the PDF document. Specifically (as a client-side only toolkit), the following two methods:
a) cookie-based secret, passed as URL parameter in GET requests. So every OAT.AJAX.GET invocation will
- set a cookie called 'oatSecurityCookie' to some random value
- add 'oatSecurityCookie=xxx' to URL string, where xxx equals to the random value mentioned above.
b) enhanced JSON parser with smarter text analysis, effectively filtering out
- comments (at the beginning and end of JSONified text)
- the 'while(1);' trap, situated at the beginning of received text
Both methods are now mentioned in the OAT documentation. Of course, applying OAT eqipped with these countermeasures doesn't make (yet) your app secure: one must explicitely use one (or both) methods on server side, to complement OAT's security features.
To sum this up - OAT is now providing a maximum support for securing GETting JSONified data. It is up to user whether he wants to take advantage of this. We are - as (nearly) always - ready :)
04/04/2007 04:18 GMT
|
Modified:
12/29/2017 13:21 GMT
|
|
|