One of the most useful concepts covered in the book, Creating Dashboards with Xcelsius — Practical Guide, is that of creating reusable property sheet patterns for use across all of your FleXcelsius projects. This is a rather lengthy topic that deserves a few chapters dedicated to it. It is only briefly touched on in the book, but just by reading about the concept, developers who are starting to work with the SDK and who aren't familiar with creating base Flex components and classes, will be immediately armed with the knowledge of the common functions they should begin looking at abstracting away into a base ActionScript class. If you're creating 3 or more custom components for SCDD/Xcelsius, you will want to create components that you can reuse as it will make your projects, now and future, much more manageable.
Below is a section of that content from Creating Dashboards with Xcelsius — Practical Guide. Stop by next week, as I can show a functional example of a very simple property sheet base class that you can start extending on.
Generating Reusable Property Sheet Patterns
If you are creating a single component with no plans to develop future Xcelsius Flex components, it is hardly worth the effort to abstract away repetitive Property Sheet functionality into a set of base classes and controls. However, if you are creating or could see creating 3 or more custom components in the future, it is recommended to create at least some basic MXML components that abstract away the often repetitive boiler plate Property Sheet code necessary to facilitate binding operations and specifically Sub Element Binding operations. If you do not take the time to create these components, you will quickly find yourself deep in code that is repetitive in nature and difficult to debug and manage. By creating basic reusable patterns for Xcelsius Property Sheets, your Property Sheet code base can likely be cut in half and in some cases, by more than 70%.
At least a 20% savings can be attributed to creating a single MXML TextInput component that serves as a Bindable Xcelsius text input property facilitator. With a couple of View States and a handful of properties, you will quickly see that by leveraging the power and Flexibility of the Flex framework and layout structure, you can quickly generate huge code savings with a bit of effort.
The primary 3 items suggested for creating MXML components or base ActionScript classes for are:
1. The Property Sheet itself. Create a new ActionScript class that extends mx.core.Application, and add the common event handlers, variables and repeated private and public functions found as a common thread through the majority of Property Sheets...
2. initiateBind
The initiateBind function, as your Property Sheet's grow in the number of custom component properties they are responsible for managing, becomes a large source and primary contributor to Property Sheet clutter and code duplication, specifically in instances where Sub Element Binding needs to be supported. By creating a generic initiateBind function with some additional embedded intelligence, you will likely be able to account for 90% of use cases. In outlying cases where the base class' initiateBind function is not suitable, you still have the option to override the base class' function, implement any custom logic for your outlying use case and then subsequently call the super class' initiateBind method to support the rest of your Property Sheet's initiateBind functionality, i.e. in your Property Sheet implementation that uses your ActionScript Property Sheet base class...
3.continueBind
The continueBind function, as your Property Sheet's grow in the number of custom component properties they are responsible for managing, also becomes an additional large source and primary contributor to Property Sheet clutter and code duplication, specifically in instances where Sub Element Binding needs to be supported. By creating a generic continueBind function with some additional embedded intelligence, this is another case where you will likely be able to account for 90% of use cases. In outlying cases where the base class' continueBind function is not suitable, you still have the option to override the base class' function, implement any custom logic for your outlying use case and then subsequently call the super class' continueBind method to support the rest of your Property Sheet's continueBind functionality, i.e. in your Property Sheet implementation that uses your ActionScript Property Sheet base class...
