PDA

View Full Version : BorderLayout



jack.slocum
1 Nov 2006, 9:18 PM
Hi Jack - I've been collecting a list of possible bugs that I've encountered while implementing a small app. I'll post a summary here but please let me know if you'd rather I discuss this in the forum?
* Given a layout and a sublayout added as a center panel of the layout: if you remove the sublayout and then add it in, the sublayout's region dimensions are wrong. Specifically I found that the north region was now 0 height. I was doing this because I wanted to hide and show elements without a visible tab bar - my workaround solution was to CSS hide the tab bar, but this is a bit hacky because there's no easy way to identify a specific panel's tab bar. The generated DOM doesn't have predictable IDs, at least that I could see? It would be nice if instead of sequentially numbering them the IDs were based on the ID of the DIV that owns the layout...
- also note (not a bug) that the add/remove region code is not very forgiving about removing something that wasn't added. In other words, if you're conditionally adding a panel but at some point unconditionally want to ensure it's been removed, you're stuck with tracking it (there might be some way to do "panel exists in this region?" but I didn't see it)
* I do think that the problem I mentioned in the comments above is a bug. I cannot get a subpanel to reliably respond to changes in the size of north content. For instance if I change the north region to make it smaller, the center panel keeps its layout, leaving whitespace where the north panel used to be. But if I make the north panel bigger, the center panel does shrink. That's why I think I'm doing the right thing but encountering a bug.
- Note that it may very well have something to do with the measurement of absolutely positioned panels... I'm still not able to measure the true height of content within the north region - the code you provided (whether clipping or not) always returns the fixed height of the panel.
- Note #2 that I pretty much suck at javascript so that could easily be my fault.
* When autoscrolling I am seeing a case where the scrollable region gets an unnecessary horizontal scrollbar. The extra scroll space is the width of the right-side vertical scrollbar. I can see from your blog itself that this doesn't always happen, but I'm not doing anything drastically different in my code, so it may be a corner case that I'm excercising...
* Given two tabs (panels) in the same region, and flipping back and forth between them: if I hide() and then show() an element in one panel, and then flip to the other, the element from the now-hidden panel remains absolutely positioned on the screen while the other panel is displaying.
I can help you debug these if you tell me where to look; I can also show you my working project - it's pretty simple code but is work for a client so I can't post the URL here, I'd have to mail it to you.
(Part of the reason I suck at javascript is because I can't find any good tools for debugging. Can I ask what you use to debug your scripts? I have FireBug but it's not very good at giving stack traces, etc. :( )
Thanks again for your work on this excellent package. Despite any bugs I'm encountering it's still saved me MANY hours of time.
Steve

Hi Steve,

1. This led me to one hard to track bug. Basically, when you remove the last panel, the activePanel was not being reset. From that point on the region became unstable because it was trying to adjust the size of the panel which was removed (a panel that has no parent node, and therefore no height or width). This has been fixed and you can add and remove nested layouts like any other panel.

2. The add and remove code has been redone to be forgiving. There is also a new hasPanel(p) method which checks not only if the panel exists, but whether it is a member of this region. Panels can also be accessed by index as well as id.

3. This extra scrollbar is usually caused when you have too many autoScroll:true set. I would recommend starting with no autoScroll:true and adding them as needed. Having autoScroll:true on a container with a nested layout could cause this as well although the layout code tries to correct it for you automatically.

4. If you have an absolute positioned element it's visibility becomes tied to it's offsetParent not it's parent element in some cases (if not all). Show show/hide would have no effect on it unless you set the element being shown/hidden as the offsetParent (position:relative or absolute).

5. I use IE + VS2005 for debugging. There is no better combo for debugging IMO. They make FireBug look like a toy.

Another new feature which I think will save you a lot of coding is hidePanel(panel or id)/unhidePanel(). All they do is hide the tab so it is invisible.

SteveEisner
1 Nov 2006, 9:31 PM
Thanks, Jack. Great to see that it helped you track down a bug.

Re: autoscroll,
Here's the sample code of my layout



// Buncha random panels. Don't need to worry about specifics, just listed here in case it's fitToFrame that causes problems?

headerPanel = new YAHOO.ext.ContentPanel('header', {title: 'Header', fitToFrame:true});
footerPanel = new YAHOO.ext.ContentPanel('footer', {title: 'Footer', fitToFrame:true});
taskTabsPanel = new YAHOO.ext.ContentPanel('taskTabs', {title: 'Task tabs', fitToFrame:true});
homePagePanel = new YAHOO.ext.ContentPanel('homePage', {title: 'Home Page', fitToFrame:true});
nextStepsPanel = new YAHOO.ext.ContentPanel('nextSteps', {title: 'Next Steps', fitToFrame:true});
peopleHomePanel = new YAHOO.ext.ContentPanel('peopleHome', {title: 'People Home', fitToFrame:true});
hireTaskGridPanel = new YAHOO.ext.ContentPanel('HireAPersonGrid', {title: 'Hire a Person', fitToFrame:true});
hireTaskListPanel = new YAHOO.ext.ContentPanel('HireAPersonList', {title: 'Hire a Person', fitToFrame:true});
taskMenuPanel = new YAHOO.ext.ContentPanel('taskMenuDropDown', 'Task menu');


// create the task layout
taskLayout = new YAHOO.ext.BorderLayout('taskLayout', {
north: {
split:false,
initialSize: 137,
autoScroll:false,
collapsible:false,
titlebar: false
},
center: {
autoScroll:true, // <-- the only one that autoscrolls
titlebar:false,
tabPosition: 'top'
}
});

taskLayout.beginUpdate();
taskLayout.add('north', taskTabsPanel);
taskLayout.add('center', hireTaskListPanel);
taskLayout.add('center', hireTaskGridPanel);
taskLayout.endUpdate(true);
taskPanel = new YAHOO.ext.NestedLayoutPanel(taskLayout, 'Current Task');

// create the main layout
frameLayout = new YAHOO.ext.BorderLayout(document.body, {
hideOnLayout: false,
north: {
split: false,
titlebar: false,
initialSize: 190,
collapsible: true
},
south: {
split:false,
initialSize: 25,
titlebar: false,
collapsible: false,
animate: false
},
center: {
titlebar: false,
autoScroll:false,
tabPosition: 'top',
closeOnTab: true,
alwaysShowTabs: false
}
});
// tell the layout not to perform layouts until we're done adding everything
frameLayout.beginUpdate();
frameLayout.add('north', headerPanel);
frameLayout.add('south', footerPanel);
frameLayout.add('center', homePagePanel);
frameLayout.add('center', peopleHomePanel);
frameLayout.add('center', taskPanel);
frameLayout.add('center', nextStepsPanel);
frameLayout.endUpdate(true);


This causes the scrollbar problem (for both FF2 and IE7) on the inner, autoscroll area. The contents of that panel are a simple long list of DIVs with text, nothing fancy.

I haven't had time to isolate a small repro case but will do so after I present my work in progress to the customer ;)

Thx
Steve

tryanDLS
2 Nov 2006, 7:51 AM
Jack,

I've always found IE + VS2005 painful for debugging straight JS code - it's great for C# tho.

I use FF + Venkman - not as full featured as VS2005, but definitely better than Firebug. I tried Firebug and didn't get what all the raves were.

That being said, I'm working with a bunch of people that don't use FF, so they'd be better served by VS2005. Have you ever come across any articles/tutorials that walk thru debugging in VS2005 when you just want to debug clientside code? It seemed kind of cumbersome to breakpoints to hit.

jack.slocum
2 Nov 2006, 1:31 PM
Well, I don't use breakpoints. :) If I need a breakpoint I add "throw 'wtf'; in the code hehe. This shoots it straight into the debugger.

rodiniz
3 Nov 2006, 3:56 AM
Copied from my blog...
Debugging Javascript in Visual Studio .NET
Open in Internet Explorer Tools -> Internet Options -> Advanced tab.
- Deselect the following (make the checkbox unchecked):

[ ] Disable Script Debugging

- Restart IE.
Now just add the following line of code to your JavaScript - it'll work as a breakpoint:

debugger;

Visit your page with the javascript using your fresh instance of IE, a window should prompt you to select a debugging environment. Select the MSVS.NET instance you have opened (or you could select 'New instance of Microsoft Development Environment'), and click 'Yes'.

Another window will prompt you to 'Choose the program types that you want to debug:' - make sure 'Script' is the only option selected, and click 'Ok'

jbowman
3 Nov 2006, 4:07 AM
I haven't implemented it in my new work in progress yet. But I find the YAHOO log system that comes with yui very useful also.