Community
Participate
Working Groups
I was hoping to quickly steal the toggling splitter in the eWebBorderContainer for the navigators. Unfortunately it currently assumes that it lives in an editorContainer, and it stores its settings to a particular location, thus it can't be reused as is. I started hacking it and realized I was starting to go off on a tangent. - client should pass in the DOM ids of any important panes (right now it is using "editorContainer") - client should specify what the setting name should be for storing the location info (so different pages could use different settings) - could we take the split management code out of editorContainer and put it in the splitter? So that pages using the splitter don't have to get involved in the size lookups, etc.?
It'd be nice to be able to close favorites from the navigators. Libing, is this something you could easily do or should I give it a shot?
I'm going to be doing some refactoring in editorContainer, so I'll take this as a to-do.
Fixed. Moved what used to be in editorContainer (and temporarily in the coding glue splitterMgr) to the eWebBorderContainer. > - client should pass in the DOM ids of any important panes (right now it is > using "editorContainer") Since the code that used to look up the panes by id is now in the border container, it knows which panes are where and we don't need to pass in anything. > - client should specify what the setting name should be for storing the > location info (so different pages could use different settings) This is no longer a problem. It was a general issue with border container. It was fixed when we fixed bug 338764. See bug 338764 comment 6. > - could we take the split management code out of editorContainer and put it in > the splitter? So that pages using the splitter don't have to get involved in > the size lookups, etc.? Done
