[2.0b1][CLOSED] (Bug? Not a bug?) getLeft/setLeft, etc - API oddity

**tjcrowder** · 21 Oct 2007 1:23 AM

Hi folks,

Consider if you will this code fragment:

Code:

var box;
box = Ext.get("abox");
box.setLeft(box.getLeft());
box.setTop(box.getTop());

...where "abox" is an absolutely-positioned div with a border. It seems to me that the box should not move; both calls are no-ops. You're telling it to set its left to what it already is, and the same for top.

It doesn't move on non-Gecko browsers like IE, Safari, or Opera; it does move on Firefox (it moves two pixels right and down).

The reason it moves is that getLeft and getTop, by default, return "page coordinates" that are not the same cross-browser, not CSS coordinates, but setLeft and setTop expect CSS coordinates. (See this thread for more on the differences -- I was initially confused, but Brian and Jack sorted me out.)

There are variants of getLeft and getTop that return CSS coordinates, and it's easy to fix that code so it behaves the same on all browsers:

Code:

var box;
box = Ext.get("abox");
box.setLeft(box.getLeft(true));
box.setTop(box.getTop(true));

The "true" for the local parameter to the "get" calls tells them you want CSS coordinates. (setLeft/setTop don't have variants that use the other coordinates, so it has to be the "get" calls that change.)

So here's my point: It seems to me that getLeft and setLeft (and other pairs of apparently-reciprocal methods) should use the same units by default. Either setLeft should use the same non-cross-browser "page" units that getLeft returns if no params are provided, or getLeft should provide cross-browser CSS units when no params are provided. (Personally, I prefer the latter.) With respect, the API seems kinda funky otherwise.

Is this difference intentional? And if so, can I agitate a bit to get it changed so getLeft and getTop return CSS coordinates by default? If you really want the non-cross-browser "page" coordinates, you can use Element.getX, Element.getY, and/or Element.getXY.

Here's the full source of a page to test this behavior yourself; try it in Firefox and then in any non-Gecko browser (Safari, Opera, IE):

Code:

<html>
<head>
<title>ExtJS - getLeft / setLeft oddity?</title>
<link rel="stylesheet" type="text/css" href="../../resources/css/ext-all.css" />
<script type="text/javascript" src="../../adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="../../ext-all.js"></script>
</head>
<body>
<input type='button' onclick='repositionBox();' value='Reposition Box'>
<div id='abox' style='position: absolute; left: 50px; top: 50px; width: 100px; height: 50px; border: 2px solid black;'></div>
</body>
<script type="text/javascript">
var count = 0;
Ext.onReady(function() {
   showPos(Ext.get("abox"));
});
function repositionBox()
{
   var box;

   box = Ext.get("abox");
   box.setLeft(box.getLeft());   // Add "true" to getLeft to make this a no-op
   box.setTop(box.getTop());  // Add "true" to getTop to make this a no-op
   ++count;
   showPos(box);
}
function showPos(box)
{
   box.update("" + box.getLeft() + "," + box.getTop() + "<br>count = " + count);
}
</script>
</html>

Thanks in advance,

**jack.slocum** · 21 Oct 2007 10:18 PM

This is one of those decisions that was made long ago and hasn't changed to keep backwards compatibility. Instead additional options where added (like the true argument) to allow the set function to have an equivalent getter.

**tjcrowder** · 21 Oct 2007 10:58 PM

Originally Posted by jack.slocum

This is one of those decisions that was made long ago and hasn't changed to keep backwards compatibility. Instead additional options where added (like the true argument) to allow the set function to have an equivalent getter.

Thanks Jack. Given the sweeping changes of 2.0, might this be an opportunity to sort this out? The entry in the "1.1 to 2.0 porting guide" would basically be:

Search for getLeft() with no parameters. Wherever the hit evaluates to Element.getLeft, replace with Element.getX instead. Repeat converting Element.getTop with Element.getY. Subsequently, search for getLeft(true) /getTop(true) and remove the "true" parameter.

Pretty trivial to do as part of a port.

**tjcrowder** · 24 Oct 2007 6:43 AM

Hi again,

Just checking back on the above...

Thanks,

**tjcrowder** · 27 Oct 2007 5:27 AM

Folks,

If this were going to be done, it would be best to do it now during the beta, not later. Since there's been no response (either way) to my recommendation above, I've removed the CLOSED marker on this thread temporarily and am pinging again (I'm guessing people just gloss over the thread when it's marked closed).

Obviously it's up to the core team whether this is worth doing; I'll mark the thread closed again when a response is received (if they don't do it at the same time). As a software engineer with a fair few years of experience both creating and consuming APIs, I do strongly recommend taking this opportunity to fix this problem.

Thank you in advance,

**brian.moeskau** · 27 Oct 2007 2:18 PM

Hey TJ, don't take offense. There's lots of stuff going on right now and specific posts can easily get lost in the shuffle. If you haven't heard from Jack in a couple of days, feel free to *bump* again -- no need to justify it

**tjcrowder** · 28 Oct 2007 12:01 AM

Hey Brian,

Thanks -- I didn't take offense, sorry if it seemed that way, I just figured people were busy and understandably skipping the "[CLOSED]" thread.

**tjcrowder** · 30 Oct 2007 8:12 AM

Originally Posted by brian.moeskau

...If you haven't heard from Jack in a couple of days, feel free to *bump* again...

*bump*

**jsakalos** · 30 Oct 2007 9:15 AM

I'm asking Jack to make decision on this.

**tjcrowder** · 30 Oct 2007 9:22 AM

Thanks!

[2.0b1][CLOSED] (Bug? Not a bug?) getLeft/setLeft, etc - API oddity

Thread Tools

Search Thread

Display

[2.0b1][CLOSED] (Bug? Not a bug?) getLeft/setLeft, etc - API oddity

[2.0b1][CLOSED] (Bug? Not a bug?) getLeft/setLeft, etc - API oddity