Relational data within flash.

Not all projects have complex data requirements, but as the “web 2.0” trend of online applications grows and flash becomes used more for importing complicated sets of data or to represent complex sets of objects more complex methods for importing and transforming data. Typical import of relational data in flash. Relational data isn’t a new concept to programming, its common within even basic database designs. Getting data into flash (8) commonly happens through XML, remoting, and LoadVars; but turning the data into meaningful information is another task completely. One awesome feature of XML is its ability to include a relational structure of any design. Flash developers have used recursive object translation to transform XML into an object structure, XML structures get crawled through to create a series of objects. Recursion limits have been put into place for good reasons, but this can limit good programmers that may not have control on changing depth of data. Several issues can prompt the need for a more abstract structure of data.

• Dealing with deep recursion shapes.
• Working data structures that are not tree shaped.
• Working data structures that contain complex networks of relationships.
• Reduce redundency of data.

Object Oriented data structures. The more applications and interfaces that use external configuration data to drive functionality in flash the more OOP principles should be used. Pulling in data and transforming it into an actual data object is one way of transforming data to be more meaningful information. From there the configurations can be used to translate into functional uses. Steps for loading and translating relational data within flash. Load in a set of data that gets turned into specific set of objects.

These object represent the objects that are related to each other. Could be people that have relationships to other people, folders that contain sub items, items or groups of items,

Collect the newly created objects so they can be accessed by unique identifier.

Using the identifier and a hash collection allows for cheap quick access to these data objects. This should probably be controlled by its own object.

Load in a set of data that represents the relationships between objects.

In database design relation tables contain the connections between different data in other tables. Usually they contain a column for a unique id and a column of ids for one set of data and a column of ids for the second set of data.

Apply the relationship data to the objects

The objects are then connected with references to each other. No recursive data crawling, and a very fast object creation method; typically spinning though collections.

Post object relationship connection. Objects now have all of their connections. These connections can then be called upon for functional requirements. Trees and networks of all sorts can be described easily. Additional objects and relationships can be added easily due to these loopup hashes. Former objects and their relationships can be removed. Updating a single object becomes even simpler. With a simple Ruby on Rails CRUD application or a different application for allowing updates to databases, if the data that creates the objects is all grouped together, updating takes little logic to describe it. In conclusion. Depending on the project or application and data requirements there may be a need for a different abstraction of relational data/ object creation. The more complex projects I work on the more this seems to simplify the project and the data transfer.