As of version 2.0.11, MegaZine3 sports a resource abstraction layer, allowing much more flexibility in the way data is loaded.

This may sound scary, but it's just the shortest way of putting it. What it means is, that instead of just being able to load files from the actual filesystem - be that on the server or locally - it is also possible to load files directly from other sources. Examples for such sources would be:

• data embedded in the SWF (via the "library" of a SWF available in the Flash IDE, or using Flex's [Embed] tag).
• ZIP files, containing the actual files.
• an actual database.

The first two (embedded data and ZIP files) have existing implementations (although the ZIP one was not in the release candidate). A database as a data source is much too individual to allow a 'default' implementation, so this will be up to each individual's explicit case to write.

[edit] How to use

[edit] ZIP files

This is pretty simple when used together with MegaZine3. In the book definition, you can declare ZIP file names to add as data sources, like so:

<book>
  <zipfile>data0.zip</zipfile>
  <zipfile>gui.zip</zipfile>
  <!-- actual book content -->
</book>

The data inside the ZIP files will all be relative to the basepath of the MegaZine3 instance, normally the folder containing the megazine.swf file. If the gui.zip from above would contain the normal gui folder, with all the ASUL files, for example, they would be used instead of the ones in the actual gui folder. In case of missing entries, the file system would be used, as a fallback.

The obvious limitation of this is, that the ZIPs cannot contain the book definition. For this, the only solution is embedding the file. Note, however, that is perfectly possible to "chain" the two, i.e. embed ZIP files and make those available, too. This is done for the ASUL and localizations (gui and langs folders) for the fat clients. See the Assets class for how it works.

[edit] Embedded data

This method will require you to write and compile ActionScript 3.

[edit] Embedding

The first step is to actually embed your data.

• When using the Flash IDE, you can use elements in the library, as long as they're available to the code (mark the "Export for ActionScript" checkbox in the properties window, and make sure to remember the name).
• Otherwise (or if that's less of a hassle for you), use the [Embed] tag. For example when in a class:

[Embed(source="/mysound.mp3")]
private static const MySound:Class;

or when in the Flash IDE:

[Embed(source"/mysound.mp")]
var MySound:Class;

(the IDE will probably ask you to update your classpath in that case, just click yes and publish again)

[edit] Registering

The second step is to register the resource with an embedded bundle, and add the bundle to the (default) resource provider.

var bundle:EmbeddedBundle = new EmbeddedBundle(stage.loaderInfo);
bundle.addResource("mysound.mp3", MySound);

And that's it! When embedding multiple resources, you should add them all to the same EmbeddedBundle, and not create an extra bundle for each one. Note that the embedded bundle needs a LoaderInfo object to resolve relative paths to absolute ones.

Adding different types works the same. In some cases, e.g. when adding text files of unknown extensions (like .mz3), it might be necessary to explicitly declare the mime-type. In that case, the [Embed] would look like this:

[Embed(source="megazine.mz3", mimeType="application/octet-stream")]

For other mime-types / filetypes try google.

A special case are custom classes deriving from Sprite. These can also be registered and be loaded like normal SWFs. This is done for the plugins, for example.

[edit] When to use

As with many features and settings, it is always important to consider whether it makes sense to use it. The embedded and ZIP variants make sense for a certain amount of data, for example the basic engine files, such as ASUL, localizations and plugins. This is the case for the fat client SWF and SWC.

For server based publications, in particular, any actual book content will likely not make a lot of sense, as it only increases initial waiting times and increases memory usage.

In general, including actual book content in the SWF itself should be considered carefully. For books of a certain size (depending on the actual page content, so no numbers here) it will be a bad idea to wrap everything into internal storage, as it will all have to be stored in memory, regardless of page visibility / load states. Imagine it as (very very roughly) equivalent to a book where the number of maximum loaded pages equals the total page count.