That said, if serializing and deserializing your model directly in your View classes works in your application, than so be it. Although, to me, and my limited understanding of what you are specifically working on, that raises a red flag. For example, what if the data source ( whether it be an RSS, a Web Service, etc. ) returned a data structure that was a far cry from the true object models in which you software operates on? And what if there are multiple services that we need to work with?

Generally speaking, I like to handle this in the Model layer of the software. The various Views and Controllers only know of specific OO Model types. What you end up with is an intermediary object that does the serializing and deserializing and interfaces directly with the data service. If you want to collect data from various sources ( as mentioned above ) you can then write additional intermediary objects that de/serialize those structures. But the important part is that the response from those data services is funneled back through those methods into a common set of Model objects. These objects are understood by the softwares VC’s and are not coupled with the data services that their properties are populated from. In a nutshell, while it may be easy to parse the XML straight in the View it will ultimately lead to tighter coupling. Just think of it this way, “What is the the responsibility of the View?”.

Again, great thoughts! I’ll check back here more often. Take care man.

JP

That’s pretty darn cool. I’d known about this ability in Flash, and having wide experience in 3D modeling and animation, I’ve very used to the concept of IK. It’s about time the added the ability of IK and, subsequently, chains in Flash.