bugs :)

[datanasov]

I noticed two small bugs.

1. Program bug. When the url of the visted page end with some link splited by dash for example - www.example.com/en/about-us or www.example.com/en/our-clients, the statistics display that page only with the first part - "about" or "our" and ignore the text after that - "us" or "clients". This will be a bid of problem if the url contains id of the product for example - www.example.com/en/product-345.
2. Design bug. Under Google Chrome in the main page of the statistics - the head of the panel named "All" is at the place of the current day and all other panel heads are pushed with one to the right side.

[arash]

1. Program bug. When the url of the visted page end with some link splited by dash for example - http://www.example.com/en/about-us or http://www.example.com/en/our-clients, the statistics display that page only with the first part - "about" or "our" and ignore the text after that - "us" or "clients". This will be a bid of problem if the url contains id of the product for example - http://www.example.com/en/product-345.

Thanks! Didn't know about that, will be fixed in b4.

2. Design bug. Under Google Chrome in the main page of the statistics - the head of the panel named "All" is at the place of the current day and all other panel heads are pushed with one to the right side.

Currently TWatch interface is only tested under FireFox 3 , IE 7 and IE 8 but Safari and Chrome will also be fully tested and supported before the final 0.3 release. keep posting the bug reports I'll need them when I get to that :)

thanks,
Arash

[arash]

Bad news about the bug in Chrome :(

That happens because unlike almost any other browser out there chrome doesn't maitain the order of object members with numerical keys in JavaScript. I heavily rely on that behavior in TraceWatch's JavaScript code.

Their rationale is that this behavior is not required by the ECMA Script specs. I don't get it, when some behavior brings a lot of convenience, is the logical and expected behavior and almost everybody supports it you don't just drop it because it's not in specs, you add it to specs. I think they are just trying to win the "fastest, lightest browser" contest by dropping such features, That's not acceptable.

So for now Google's Chrome browser is not supported by TraceWatch until this issue is resolved. Sorry.

Arash

[datanasov]

That's bad indeed.

Here's first possible solution I think about.

Two dimensional arrays:
var arr = new array();
var arr[] = array("one"=>true);
var arr[] = array("three"=>true);
var arr[] = array("four"=>true);
and the end output target will be something like:
arr => 0 => one = true
arr => 1 => two = true

where the index number is just to make sure that the data is sorted by the insert order
arr[0]["one"], arr[1]["two"] and so on...

you can easily using this in your cycles without care about the index number
foreach(arr as record)
{
var key = "";
var value = "";
foreach(records as k=>v) {key=k;value=v;}
alert(key);
}


So for the places where sorting(by insert order) is needed you can implement this way, if you think that have sense.



Dimitar

[arash]

There are easier/cleaner ways to work around this too but these are all HACKS. If this was an isolated problem and not something like primitive objects which I use everywhere in TraceWatch code I would have considered such solutions, but supporting a single browser with little user-base is not worth the negative effect such hack will have on readability, manageability and performance of the code.

[arash]

Since Opera is going the same way and combined Opera and Google Chrome user base is significant I fixed this problem in TraceWatch version 0.335. Google Chrome is now officially supported.
But I still think an ordered associative array (like PHP's) is extremely useful in many situations and there is no clean, elegant way to simulate it. I really hope in future such functionality be a part of ECMA script specs.