For years, many Flex developers have known the secret to fixing many a UI problem was using either callLater() or validateNow() methods. Much to my surprise, some of these developers do not understand WHY these fix problems, what the difference is, and which method to use.

The Problem

So why do we need these functions? Well, in short, the flex framework doesn't do anything in the order you tell it and it doesn't do what you tell it to do when you tell it to. If you set a text's width and a text's style, they may not be applied in that order. And they will probably not be applied until a bunch of other stuff has happened either. When a programmer thinks something is done synchronously (one after the other) when they're actually being done according to the component when it "validates". It is important to note that this is not an issue with ActionScript 3, so much as an issue with the Flex Framework.

callLater vs. validateNow

callLater accepts two parameters. A function and some arguments for the function. This "function" gets queued to be called again at a later frame, hopefully after everything else has finished processing. I blogged about this before but I failed to mention the real difference between this solution and validateNow.

validateNow accepts no parameters and basically tells your component to just do its processing RIGHT NOW! So the difference is, instead of waiting and executing, like callLater, it just executes right now. From a programmer's perspective, this is a lot easier to do, however, it is not faster. It forces Flex to reprocess a bunch of stuff, whereas callLater just executes the code you wanted to execute anyway at a later time. If you want to use validateNow, consider that there are some more specific functions such as validateSize, validateProperties, and validateDisplayList. All 3 of these functions are called by validateNow.

Code vs. Code

The situation is that you want the width of some rendered text. After setting the text, you can not get the measuredwidth property because it will still be 0 until the component has validated.

CallLater Solution

var someText:Text = new Text();
someText.text="testing";
addChild(someText);
trace("before: " + someText.measuredWidth);
callLater(getWidth);
public function getWidth():void{
     trace("after: " + someText.measuredWidth);
}

validateNow Solution

var someText:Text = new Text();
someText.text="testing";
addChild(someText);
trace("before: " + someText.measuredWidth);
someText.validateNow(); //you should actually use validateSize() if you just want the measured width
trace("after: " + someText.measuredWidth);

Hopefully this makes sense. In my opinion, it is generally better to use callLater as it won't cause any unneeded computation.

Addendum: invalidate functions

Unless you are writing your own component you won't need to worry about invalidateSize, invalidateDisplayList, and invalidateProperties. These are basically "make dirty" functions that tell flex "this component needs to run a validate function." If for some reason, a component (perhaps a custom component?) is failing to calculate or display something, these functions are an efficient way to tell the component it needs to do some processing. The Flex framework uses these functions internally to avoid unnecessary executions of the validate functions mentioned above.

I installed the latest build of Drupal 7, and I must say, it is going to rock! Many complaints against usability have been addressed.

This site is running on D6 and I just installed the Fusion base theme and I'm playing around with it. I'm really excited to use Prosper on an upcoming project. Those guys and gals over at TopNotchThemes know what they're doing.

If you're trying to do case-insensitive files with Drupal, forget about it! Unless you redo the whole mod rewrite stuff. basically when you request a file, the mod_rewrite shoots it through Drupal first as a query param. Even if you turn on CheckSpelling in apache, it won't work. I don't have a solution, except not to use mod rewrite or clean URLs. OR... not use CheckSpelling which is what most security experts recommend anyway. Make your choice!

A lot of times, people want very specific functionality out of a jquery menu. There are at least 5 or 6 decent jQuery accordion menu plugins out there. But they're all overkill in my opinion.

A jQuery accordion can be as little as 3 lines of code. Here's one in 7 lines of code. And if you do some chaining, probably even less.

$('#accordion li ul').hide();
$('#accordion li a').click(function(){
	$(this).parent().addClass('selected');
	$(this).parent().children('ul').show('fast');
	$(this).parent().siblings().children('ul').hide('fast');
	$(this).parent().siblings().removeClass('selected');	
});

So how does this work? The first command hides all the sub-menus. Then you add a click listener to the item itself. When you click it, you add a "selected" class to its parent list element. That way you can style it appropriately if it is selected. Then you show the sub menu on the next line. Finally, hide all the siblings and remove their selected classes. Now, assuming you've got the CSS, XHTML structure in place... that's it. You are done my friend.

<ul id="accordion">
    <li><a>Item</a>
        <ul>
			<li><a href="#">sub item</a></li>
			<li><a href="#">sub item 2</a></li>
			<li><a href="#">sub item 3</a></li>
		</ul>
    </li>
	<li><a>Item 2</a>
        <ul>
			<li><a href="#">sub item</a></li>
			<li><a href="#">sub item 2</a></li>
			<li><a href="#">sub item 3</a></li>
		</ul>
    </li>
	<li><a>Item 3</a>
        <ul>
			<li><a href="#">sub item</a></li>
			<li><a href="#">sub item 2</a></li>
			<li><a href="#">sub item 3</a></li>
		</ul>
    </li>
</ul>

Very basic nested list elements.

Now let's add some CSS.

#accordion li a{cursor:pointer;text-decoration:none;}
#accordion li.selected {font-weight:bold;}

Here's a demo.

• Item
  • sub item
  • sub item 2
  • sub item 3
• Item 2
  • sub item
  • sub item 2
  • sub item 3
• Item 3
  • sub item
  • sub item 2
  • sub item 3