jack.slocum
11-02-2006, 12:18 AM
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.
* 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.