AlignLayout manages alignment and offsets relative to its Container

[dnalot]

This is a layout that enables anchoring of contained elements relative to the container's specified anchor points. If the container is resized, all anchored items are automatically rerendered according to their anchor rules. This class is intended to be extended or created via the layout:'align' Ext.Container.layout config, and should generally not need to be created directly via the new keyword.

AlignLayout does not have any direct config options (other than inherited ones). However, the items added to an AlignLayout can supply an anchoring-specific config property of align which is a string containing two values separated by a dash, the first value is used as the element's anchor point, and the second value is used as the container's anchor point. This value is what tells the layout how the item should be anchored to the container and is passed into Ext.Element's alignTo method with any x/y offsets using the standard x and y component config options.

The items added to an AlignLayout can also supply the standard width and height component config options as integers or percentages based on the size of the container itself. Any negative or zero value is subtracted from the container's measurement to calculate remaining size.

New demo (http://www.docudesk.com/scripts/ext/demos.html) based on the BorderLayout Sample and showcasing the sexy Slate theme B)

Updates
-- 2008-02-11 --
[fixed] - All components now positioned absolutely to preserve placement e.g. if panel collapses
-- 2008-02-12 --
[fixed] - Closure corrupting style property of contained items
[fixed] - Size value of 0 intended to be equivalent to (-0) i.e. '100%'
[added] - Single side align values now double themselves or accept BorderLayout region identifiers for convenience e.g 't-t' is equivalent to 't' as well as 'north'
-- 2008-02-14 --
[changed] - Cleaned up globals in closure
-- 2008-02-15 --
[added] - Demo
-- 2008-02-17 --
[fixed] - Position against items' getPositionEl() rather than el itself
[changed] - Added dependency for internal use
-- 2008-02-20 --
[fixed] - Oversight in applying position
[changed] - Updated demo in response to post
[added] - New pseudonyms for corner alignment e.g. 'nw' is equivalent to 'tl'
-- 2008-02-28 --
[changed] - Corrected namespace
-- 2008-03-05 --
[fixed] - Style persistence between instances
[added] - Use position property in Container config to specify item positioning which defaults to 'absolute' and false is equivalent to 'auto'

[svdb]

Hi,
I'm looking to use alternative layout implmentations to solve specific issues.
What would be the advantage of your implementation over the standard border layout for instance?
Thanks,
svdb

[dnalot]

AlignLayout has the flexibility to emulate almost any other layout. unlike BorderLayout, items are not stuck in their respective quandrants. Instead, they are positioned and sized relative to them. My particular implementation inhouse has controls that float over an active workspace. This can be achieved manually, but AlignLayout manages and lazily initializes them to lighten your startup code. The primary distinction from other layouts is overlapping with relative alignment to the Container.

[svdb]

Ok thanks for the feedback. I'll give it a try asap.
Cheers

[sgodden]

I have a couple of issues trying to use this layout:

1) When sizing the browser down, right-anchored components don't reposition properly
2) If you keep laying out the surrounding container, right-anchored components shift right 1 pixel each time

Maybe I'm using it incorrectly - here's the code:


Ext.onReady(function() {
var viewport = new Ext.Viewport({
layout: 'border',
items: [
{
region: 'north',
height: 50,
layout: 'align',
items: [
{
align: 'west',
html: 'West'
},
{
align: 'br',
html: 'East'
}
]
},
{
region: 'center',
html: 'Center',
buttons: [
{
text: 'Do layout',
listeners: {
click: {
fn: function(){
viewport.doLayout();
}
}
}
}
]
}
]

});
});

[Animal]

Sounds very cool, but I'm getting a 404 from that demo page.

[dnalot]

sgodden:
extremely clever test case i commend your constructive feedback!

i actually have been meaning to write thorough documentation and post it on a blog and hadn't updated the code in this post in a while. in any case, the issue persisted in my most recent revision.

as far as i can tell the issue is as follows:
1. my 'align' values internally call Ext.Element#alignTo
2. alignTo in turn calls getAlignToXY which in turn positions the top and left using the difference between getAnchorXY results
3. getAlignToXY, for a reason i failed to fully assess, calculates the left wrong by 2px every time (even though the path for obtaining the top value appears identical yet works)
4. the issue compounds itself because getAnchorXY only accounts for the visible portion of the element which keeps getting lopped off

in the most version which i will upload tomorrow there is an 'alignEl' config property in which you may specify a different element to align to, but, alas, it only decreases the rate to 1px of movement. lemme give it another look tomorrow and i'll come back w/ a fix. thx again ~ t

[dnalot]

animal:
thx man i've read a lot of your posts. i've been intending to put together a more useful demo but i'll get the old one back up tomorrow. been a bit distracted by flash lately. thx for checking out my extension!

[dnalot]

as promised updated demo link. will update everything else as time allows or interest shown.

sgodden:
thanks again we actually just ran into this internally too. there are actually two separate issues at hand which you can view yourself by toggling overflow on the two parents of the dom element in question:
1. alignTo is doing a 1px border miscalculation on both width and height.
2. both ff and ie seem to throw away the overflown width of the element (but not height)? i couldn't even find it in the firebug dom tab! instead you only receive the visible width which is off by at least 1px b/c it's obscured by the border it aligns against. this value in turn miscalulates the new left offset.

having identified the problem, the workaround was straighforward. aligned components accept offsets from their alignment position. your magic offset is [-2,-1]:

{
align : 'se',//synonym for br
x : -2,
y : -1,
html : 'East'
}

[sgodden]

OK great stuff.

With your latest code, and changing my code as you suggested, the 1px miscalculation is definitely fixed. :)

But, when sizing the window down in FF and IE, it still does not lay out properly (East disappears). You have to size the window back up again to get it to snap back.

I have no idea how to fix this, and had the same problem myself when trying to do this stuff, but presumably it should be possible to work it out from the code in other Ext layouts, since they handle sizing down fine (for instance, the container which has the buttons at the bottom of the sample code I gave handles it fine).

[sgodden]

Of course my last reply is potentially a bit stupid, regarding looking at the other layouts. If they're just using tables then of course they'll work ok....

[dnalot]

no worries i should have noticed this before i sent the workaround. it's the same issue where Ext's getAnchorXY fails to assess width on elements hidden by their parent. i will attempt to provide a real resolution tomorrow.

[dnalot]

my fix was to blow away any pre-existing left value and add a right value to prevent the element's overflow from getting hidden by its parent. now that i think about it i'll move this fix to intercept the Ext code itself tonight and will put this bug on my list to track on the forums later. in any case great feedback and should work now.