From my perspective, the main limitation of that program was that it used absolute layout, meaning each element needed to be manually placed using the x and y attributes. Frankly, that's pretty lame. Even as I wrote it, I knew I'd have to learn about Flex's layouts.
Since that time, I have. And thus far, they seem to be both powerful and simple. They beat the pants off of both HTML and Swing, which were the UI technologies I had compared Flex to.
The layouts are based on the concept of containers. A container is an element in which other elements can be placed (whether they're other containers or actual UI components). The containers have different properties that control how things are laid out inside them.
For example, if you wanted to put two buttons right next to each other, you'd use an HBox, like this:
<mx:HBox>
<mx:Button label="One" />
<mx:Button label="Two" />
</mx:hbox>
That's much nicer than having to define the x/y coordinates and the width of both buttons.
So what did I decide to do to update my QB Rating application? I used a Form Container, with a set of FormItem containers inside it, to lay out the TextInput fields where you enter the QB's stats. And below that, I have a VBox for the results. It looks like this:
<mx:Form left="10" top="10">
<mx:FormHeading label="Calculate QB Rating" fontSize="20" fontWeight="bold" />
<mx:FormItem label="Completions">
<mx:TextInput id="completions" />
</mx:FormItem>
<mx:FormItem label="Attempts">
<mx:TextInput id="attempts" />
</mx:FormItem>
<mx:FormItem label="Yards">
<mx:TextInput id="yards" />
</mx:FormItem>
<mx:FormItem label="TDs">
<mx:TextInput id="touchdowns" />
</mx:FormItem>
<mx:FormItem label="INTs">
<mx:TextInput id="interceptions" />
</mx:FormItem>
<mx:FormItem>
<mx:Button id="calcButton" label="Calculate QB Rating" click="{calcRatings();}" />
</mx:FormItem>
<mx:VBox>
<mx:Label id="nflRating" text="" fontsize="16" />
<mx:Label id="ncaaRating" text="" fontsize="16" />
</mx:VBox>
</mx:Form>
And my oh my, is that nicer than the previous version. If you looked at the old version of the QB Rating application, it had a Label and a TextInput for each field, and the left and top attributes were set for each one. The new version actually takes up a few more lines of code, but it requires you to have less extensive knowledge of the size of the elements. For example, if you decide to change the font size of one of the elements, you won't have to change the "top" attribute on everything below it. If you change the title of one of the labels, you won't have to change the "left" attribute on all the TextInputs so they all line up and don't overlap their labels. I think that's worth a couple more lines of code.
So ... why did I learn about the absolute positioning first? Well, that's how the examples on Adobe's sites all work. At first glance that doesn't make sense, but I've recently learned that absolute positioning is the default in Flex Builder 2 (which I don't have). So it looks like the guys writing these examples are building their applications in Flex Builder 2 and then going through the generated code in their articles. I don't have a problem with that in general, but it seems to me that if you're ostensibly teaching someone about writing the code, it should be code that was actually written. That's a pretty minor quibble though, especially since Adobe's online documentation about layouts and containers is pretty excellent.
If you want to check out the new app or source code, by all means do so.
No comments:
Post a Comment