Over the last 3 days, I have studied all I could find about Movable Type assets. The current standard for associating an asset (image) to an Entry is to embed the image enclosed by the MT form tag. Using the form tag by itself does not establish association.
Besides that, tagging assets offers an amazing flexibility in choosing which asset to display where and in what size. The flexibility is such that all of your image thumbs in any Entries/Pages can be recreated automatically in a snap, should the design of the webpage change. This approach to the placement of assets requires the mt:Assets tag. The downside of this approach is that it is slower compared to using context-specific container tags (EntryAsset, PageAsset).
This leads me to the question if you could have the best of both worlds: Flexibel association of assets to Entries and fast retrieval of them. By flexibel I mean that you could establish association between an asset and an Entry/Page regardless of whether that asset (image) is actually embedded in the Entry/Page.
Here are my initial ideas of how assets could be selected and returned faster:
1. Allow the id attribute of the Asset tag to take on multiple ids.
2. Allow assets to be associated to Entries/Pages based on the IDs of Entries/Pages. For example, if I want to associate assets with IDs 1, 2, and 3 to Entry 821, I would tag those assets with entry-821. Now, in place of using regular tags, this would require an extra field I guess.
Reported on Movable Type 4.2
Hello Alex,
I was wondering whether in your detailed study you have encountered anything that might be of interest in tackling the issue of system-assets.
The idea is to be able to upload system-level assets, manage them in the assetmanager, and use them in a system wide fashion and not only a per blog basis...
I posted the query here on the forum (See http://forums.movabletype.org/2009/02/system-level-assets.html)
Thank you.
I detract from my previously favorable view on Movable Type assets. Assets are problematic because they are:
1. not implemented globally for an entire Movable Type installation.
2. to be registered by uploading files, and not by selecting folders from which the application can retrieve files as assets.
3. not made part of the Entry Import/Export format.
4. assignable to Entries, while Entries are not assignable to assets.
MT assets were not conceived to be copied from one blog to another (cloning ignores assets). With the way they are implemented now, you are left to hope that you'll never have to change the directory structure, rename folders or files, clone a blog, or whatever.
On the upside, once they are in place, use of custom asset fields and asset tags makes authoring easier and image creation adaptable to changing web designs. But who wants to live in a trap to enjoy these benefits?