Bugzilla – Full Text Bug Listing
| Summary: | [client] eWebBordercontainer broken on dojo 1.6 | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 343631 | ||
|
Description
Susan McCourt
From bug 343631: The immediate problem we run into is in our eWebBorderContainer.js: Uncaught TypeError: Cannot read property 'style' of undefined chrome-devtools://devtools/js/widgets/eWebBorderContainer.js:139 - It looks like instead if we want this functionality we will have to use container.getChildren() and iterate to find "left" or else rethink this widget There are two problems here involving use of internals:
- this._splitters no longer exists. We need to use this.getSplitter("left") or this.getSplitter("left").domNode, depending on whether the dijit or domNode is needed.
- this._left, this._center no longer exist. We need to iterate the children and look for "leading" and "center" and then use the child dijit's domNode
I have it working now and want to see if it will still work on 1.5. If so, we could release for 0.2M7, otherwise I'll make a patch.
Tested on 1.5 and 1.6. Fix works, as it switched from private field access to using methods that existed in 1.5 and 1.6. So I'm releasing it now to avoid pain later. I don't really like the way that this widget feels (as far as working with the code). It is structured as if it is a generic extension of borderContainer, but it's really a specific use case. I wonder if we could accomplish the behavior in another way, or else generalize it even more. Note that one of the methods being used (getSplitter) is marked deprecated and will be removed in dojo 2.0. Opened bug 343915 for the more general concerns. fixed. |