|
While not strictly required, most deployments will want to store the mashes created by end users on the server so they can be played back or edited again later. The XML formated mash data is passed to a CGI script on the server using the CGI control. This script can then simply store the text based data within the file system or a database for later retrieval.
As with many content management tasks though, issues of data integrity can arise that will necessitate certain data storage approaches. For instance, each mash will contain multiple clips that in turn reference media items. To recreate the mash later, both the clip tags AND their corresponding media tags need to be loaded into the applet.
Learn more in Mash Loading.
One way to get around these issues is simply to store the media and font tags as part of the mash data, making what might be called a 'fat' mash. In fact, the CGI control makes this approach easy by including an option that combines the tags together as the mash is sent to the server. Another approach could be to use a script to deliver the mash data, and have it parse through the clip tags to generate the corresponding media tags on the fly.
Unfortunately, neither of these approaches is appropriate if there's a chance that the underlying media assets might be removed or changed, since the tags within the mashes that reference them will no longer be valid. Deployments that allow media items to be updated or deleted must create some mechanism that either disallows these actions for referenced media, or somehow resolves the data integrity issues they will create.
A truly robust database approach will model clips as well as mashes, and include some sort of association to media. If modular media (effects, transitions and themes) are being modeled together with normal media, one must also account for effects that composite other media. In practice this means either a clip/media association table, multiple foreign keys or a multi-value key field, depending on your approach and storage system.
Another consideration is fonts, which share the same referencing issues as media. Often they are handled in the same way as media, but if the font selection is limited it might be simpler to just include their option tags along with the interface related tags. Another approach is to simply reference fonts generically (eg. 'serif'), and then change the underlying asset as needed (say, from 'Times' to 'New York').
| 
