After quite a bit of work, I’m relieved to present a beta release for the next version of my TreeMap component for Flex. It took me a while, but I reworked much of the core item renderer code to optimize performance, improve maintenance tasks, and generally make it a better component for everyone to use. For full details, visit the TreeMap project page and grab the new build from the downloads section. The package is marked 2.0.0 BETA.
One of the features I’d like to highlight is the new header renderer. The most obvious change is the new zoom button. Because the headers may be selected (when the branchesSelectable property is set to true), a separate zoom button is needed to differentiate these actions. Additionally, you might notice another interesting change in the example linked below. Choose the “Slice-and-Dice” layout, and you’ll see that some of the headers have a little arrow after any text that gets truncated. Roll the mouse over the header, and it will grow with animation to its optimal size, revealing the full text and the zoom button. A drop shadow makes it pop out a bit to help differentiate the header from the surrounding component. With particularly complex data providers, this feature helps usability enormously because the headers often become very small, which hides parts of the text and the icons on the zoom buttons too.
As with all beta software, a word of warning. This component is not completely tested, the documentation is obviously incomplete, and you should use this in production apps at your own risk. I did my best to get everything stable, but obviously, this is the very first release of some new code, so I know there will be bugs. If you’re feeling adventurous, though, I hope it works well for you. Should you see any strange behavior, please file a bug report so that I can make the next release better! If you have any questions, send them to the new flextreemap discussion group I set up recently so that others can learn too.
I just checkouted your component (beta2) and I am impressed. Wo. Thanks for putting those pieces together, that’s great. Everything is well seperated (I may reuse only the SquareLayoutStrategy in one of my projects..)
Thanks
{Maz}
Thanks, Maz. I’m glad you found it useful.
Hi Josh,
We have been using your treemap in a dashboard successfully for a while now, but I just ran into a problem. We included the treemap with some other components, each in their own tab. I made a second treemap on another tab -all within the same mxml file which I know is a bit unorthodox. Until recently it was working fine, but then I ran into a strange problem. we used to have the treemap setup so that “treemap1” opened up first, but if we open the second treemap first instead, we get an “error 1009:Cannot access a property or method of a null object reference.”
It seems to error out in the itemToToolTip function, on the line
if(this.treeMap.dataDescriptor.isBranch(item))
The wierd thing is, if I start with the first treemap, it works fine, if I start with the second treemap, it gives me this error.
I know this is very vague and ill-defined but I was just wondering if you might have any intuition about what may be causing this?
Nola, it’s probably caused by the creationPolicy in your TabNavigator. You’re viewing the second TreeMap first, so the first TreeMap hasn’t been created. So, when your itemToToolTip() function is called, treeMap is null. Does your second TreeMap use the same itemToToolTip() function? You might want to give it its own function. Otherwise, in the worst case scenario, you can always set creationPolicy=”always” on the TabNavigator. This setting may impact initial startup performance, though.
creationPolicy=”all” in the TabNavigator fixed the problem. I’m not sure exactly why though. as you said, it does increase load time a bit but we can live with that if necessary.
I actually did basically copy all the functions, so I have for example itemToToolTip1() and a completely seperate itemToToolTip2() etc.
I did the same for all of the key functions.
Thanks for the advice there Josh, we really love your Treemap, we think it’s the best we found of several other options we evaluated including some of the commercial ones.
N.P.
The default creationPolicy only creates components once they’re visible. When you view the second treemap first, the first treemap isn’t shown, so it doesn’t get created right away. Some of your code that references the first treemap is running, but the first treemap is still null.
yeah thats that part I can’t figure out, I thought I duplicated everything. Anyway now I have a workaround so I can just tinker with it at my leisure, eventually I’ll find it. Something to do with the
itemToToolTip function.
Pingback: Open Source Flex Component: HeatMap - Josh Talks Flash
I am attempting to use this component but with a different structure for the xml, but I seem to be failing miserably.
The structure you outline in your sample is like so
[Removed by blog software. Use <tagname> in the future!]
The system I am working with does not use this format. It returns data like so
[Removed by blog software. Use <tagname> in the future!]
I have tried allot of things but the component does not seem to be able to handle this structure. What is need to support this style.
Devver, it seems you copied your XML directly instead of reformatting it, so my blog software just stripped most of it out. I edited your comment above to make it obvious that the code is missing.
To answer your question, if your data follows a different structure than the default XML handler (called a data descriptor) used by Tree and TreeMap, then you need to create your own custom data descriptor.
You’ll want to implement the interface mx.controls.treeClasses.ITreeDataDescriptor (and possibly ITreeDataDescriptor2). See mx.controls.treeClasses.DefaultDataDescriptor to see how Adobe implemented the default version.
Pingback: treemaps « HIDIHO!