VO’s are centralized containers of business data. VO’s offer storage and retrieval of it’s own data through Getters/Setters. They are easily accessible, passed around and portable, updated and bindable. All of these factors have increased production and ease of programming on this large scale project, and attributed to the ease of use in the project.

The custom VO classes we use have lighten the load of developing a complex project through their storage of simple, and on occasion more complex, data types. VO’s are a timer saver in that one call can be made to have all the data stored and ready to use versus making multiple calls whenever a piece of data is needed, which is something you’d probably never want to do in the first place.

One more thing that makes VO’s so valuable is the ability to POST and GET VO’s in their entirety which leads to matching data in, matching data out and through this we have consistency in our data.

The value of Value Objects is immeasurable in terms of making your life easier when it comes to developing projects of any size. Just the amount of time you will end up saving makes VO’s a must in your development war chest.

Additional Resources

If you are just getting into the concept of using Value Objects in your own projects, here are some additional resources and comments on the subject:

DDD – Entities and Value Objects

Start Using More Value Objects

Domain Driven Design Community: Value Objects

Here’s a Value Object Generator worth checking out that can take a lot of the repetition out creating your own AS3 value objects.

The itemRenderer object is available in different flavors, and depending on what you would like to accomplish, there is a flavor for you. The Drop-In, the Inline and the Custom itemRenderer are three possible solutions for adding rich content and components, and can give your project a greater level of sophistication. In this example I use the DataGrid as my list-based component.

Drop-In Item Renderers

The simplest of the itemRenderers is the Drop-In. It is written directly in the MXML so even though the Drop-In can get your project to higher levels of usability, the additional effort may not make it the first choice for more complex objectives. However if you would simply like to add a component, you need only reference that component as the value of the itemRenderer property for the list-based control.

The data can be located in the MXML itself as part of the DataGrid, located in the outerDocument or as an external file. The DataGrid in this first example has the dataProvider wrapped inside the DataGrid, so there is no need to identify it as the dataProvider for the DataGrid. However, if the data to be used is outside the DataGrid control, the DataGrid would need to be made aware of the data through it’s dataProvider property.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:DataGrid>
	<mx:columns>
		<mx:DataGridColumn headerText="Song #" dataField="songID" />
		<mx:DataGridColumn itemRenderer="mx.controls.Image" headerText="Image" dataField="img" />
	</mx:columns>
	<mx:dataProvider>
		<mx:ArrayCollection>
			<mx:Array>
				<mx:Object img="images/0.jpg" songID="0" />
				<mx:Object img="images/1.jpg" songID="1" />
				<mx:Object img="images/2.jpg" songID="2" />
			</mx:Array>
		</mx:ArrayCollection>
	</mx:dataProvider>
</mx:DataGrid>
</mx:Application>

Inline Item Renderers

Inline itemRenderer’s offer a bit more in terms of flexibility. Inline itemRenderers allow you to set of properties of the components used by the itemRenderer. When using the Inline version the component you wish to use must be wrapped by a Component tag. The Component tag creates a new scope and where there can only be one root node. If you want to call a method or make use of a property defined outside that scope, you can use outerDocument.methodName or outerDocument.propertyName. I find that using parentDocument in place of outerDocument also works as well.

Notice the value for the source property in the Image component. The dataProvider attribute provides the data for the DataGrid:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
 
<mx:Script>
	<![CDATA[
		import mx.controls.Alert;
		import mx.collections.ArrayCollection;
 
		[Bindable] 
		public var inlineAC:ArrayCollection= new ArrayCollection(
			[
				{songID:"3", img:'3.jpg'},
				{songID:"4", img:'4.jpg'}
			]
		);
 
		public function firedButton():void {
			Alert.show("Button fired!")
		}
	]]>
</mx:Script>
 
<mx:DataGrid rowCount="3" variableRowHeight="true" dataProvider="{inlineAC}">
	<mx:columns>
		<mx:DataGridColumn headerText="Song #" dataField="songID" />
		<mx:DataGridColumn headerText="Image">
			<mx:itemRenderer>
				<mx:component>
					<mx:VBox horizontalAlign="center" height="100" verticalAlign="middle" width="100%">
						<mx:VBox source="{'images/'+data.img}" />
					</mx:VBox>
				</mx:component>
			</mx:itemRenderer>
		</mx:DataGridColumn>
		<mx:DataGridColumn headerText="Various Components">
			<mx:itemRenderer>
				<mx:component>
					<mx:HBox>
						<mx:Button click="{outerDocument.fireButton()}" label="Button" />
						<mx:RadioButton />
					</mx:HBox>
				</mx:component>
			</mx:itemRenderer>
		</mx:DataGridColumn>
	</mx:columns>
</mx:mx:Image>
</mx:Application>

Customer Item Renderers

A custom itemRenderer offers the most in flexibility – both in ease of reuse and in seperation. In the third DataGrid the data source is located in an external xml file and the itemRenderer is in a seperate MXML file. Having the files seperate enables the class to be repurposed and can save significant development time on larger, more robust projects.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
 
<mx:Script>
	<![CDATA[
		import mx.controls.Alert;
		public function fireButton():void {
			Alert.show("Button fired!");
		}
	]]>
</mx:Script>
 
<mx:Model id="externalXML" source="model/sample.xml" />
 
<mx:DataGrid height="300" dataProvider="{externalXML.album}">
	<mx:columns>
		<mx:DataGrid headerText="Song #" dataField="songID" />
		<mx:DataGridColumn headerText="Image">
			<!-- Example Drop-In item renderer -->
			<mx:itemRenderer>
				<mx:component>
					<mx:VBox horizontalAlign="center" height="100" verticalAlign="middle" width="100%">
						<mx:Image source="{data.img}" />
					</mx:VBox>
				</mx:component>
			</mx:itemRenderer>
		</mx:DataGridColumn>
		<!-- Example Custom item renderer -->
		<mx:DataGridColumn itemRenderer="view.customRenderer" headerText="Various Components" />
	</mx:columns>
</mx:DataGrid>
</mx:Application>

1
2
3
4
5
6
7

<!-- FILE: view/customRenderer.mxml -->
 
<?xml version="1.0" encoding="utf-8"?>
<mx:HBox height="300" xmlns:mx="http://www.adobe.com/2006/mxml" width="400">
	<mx:Button click="{parentDocument.fireButton()}" label="Button" />
	<mx:RadioButton />
</mx:HBox>

<!-- FILE: model/sample.xml -->
 
<?xml version="1.0" encoding="utf-8"?>
<externalxml>
    <album>
        <songid>5</songid>
        <img>images/AlbumArt1.jpg</img>
    </album>
    <album>
        <songid>6</songid>
        <img>images/AlbumArt2.jpg</img>
    </album>
</externalxml>

Incorporating itemRenderers into your project adds value and really opens the door for producing significantly more functional and dynamic projects. Hopefully this post makes starting down that path a little less daunting.

Over the years browsers have become increasingly standardized with some key exceptions to the rule. In order to accommodate for these variants we’ve set up a standard process to check for browser compatibility. Right out of the gates we’ll identify, with our client, the necessary browser targets for a given project. This usually runs the typical gamut unless there is something unique about the project that explicitly requires additional browsers and devices.

One key thing to note – we will set up HTML code and content beforehand so that content is laid out correctly. We will rarely begin integrating CSS until we’ve identified and setup all elements on the page.

From Newest to Oldest

Fortunately the above rule about standardization has been pretty consistent. The groups pushing the latest browsers have worked very hard to meet the standards set forth by the W3C and development community. This makes it the best place for us to start since it will help us insure that our CSS is setup to meet those standards. Once we have met the proper display requirements in these newer browsers we’ll continue through the older versions until we reach our minimum requirement.

Our first step is to select a specific browser in which to develop. This will typically be Firefox 3, or Safari 3/4. With the recent launch of Internet Explorer 8, this browser also becomes a viable option, but since our production environment is run primarily on Macs, it’s easier for us to pick one of the cross-platform browsers over Internet Explorer.

After layout, styles and sprite functionality display correctly in the latest browsers we continue down to our next tier. This tier is usually closely related to the above tier in that they use similar browser frameworks, but we run tests nonetheless to guarantee consistency. This next tier usually consists of Google Chrome, Firefox 2, and Opera.

The first two tiers will typically consist of small rendering issues – independent browser correction of CSS mistakes; incorrect style declaration that gets too browser specific, or something else similar. From here we’ll move down into Internet Explorer 7. While IE 7 showed significant improvements over it’s predecessor it still contains several CSS rendering problems. For this reason we will address IE 7 in a separate tier. Corrections made at this level will usually live in a separate CSS file that overrides previous declarations. To avoid any conflicts we’ll incorporate this new CSS file using IE conditionals that check for IE 7.

After all the above browsers have been addressed, we’ll move to IE 6, which is commonly known for it’s severe problems with rendering standards-based CSS. Following the same method taken for IE 7, we’ll finally include a conditional for IE 6 browsers that address the specific problems inherent with this browser.

Browser Version Testing Order

To review, we would go through browsers in the following order to address cross-browser CSS:

1. Tier 1: Safari 3/4, Firefox 3, Internet Explorer 8
2. Tier 2: Safari 3, Firefox 2, Opera
3. Tier 3: Internet Explorer 7
4. Tier 4: Internet Explorer 6

This approach has proven to cut down significant amounts of development time because we will have:

• avoided using potentially harmful hacks in our core CSS,
• created clean standard-based code at the top level,
• progressively corrected any issues as moved forward with development without the need having to move back up the version ladder

Of course, other browsers can be added to or removed from your list, but the idea is to move down the chain so that you avoid including erroneous code in your more standards compliant browsers.