Hi!
I decided to roll my own, after taking a look at Dror’s source code.
The code isn’t bad but I don’t want to get into patching Radiant
itself to support a plugin, seems safer to try and make it work within
the mainstream and besides, that gave me an excuse to write a Radiant
behavior.
The Asset List behavior uses an extra page part called ‘assets’ within
which the user has created a YAML representation of the assets that
need to be centralized. The format is straightforward and amenable to
machine generation.
The YAML list is organized, first by asset host (which is a URL under
which the assets are kept), and the entries under this host are the
various content types (I use mime types to organize this content, but
actually, anything can be a key since the behaviour doesn’t actually
depend on mime types.
I’ll make an example, by pointing out some of my own use cases. I keep
several files in a /files URL which contains different types of
content. I have some projects that I like to keep separate from my
personal files, and those go into subdirectories.
application/pdf:
CV.pdf: Curriculum Vitae
revenue.pdf: A Community Revenue Collection System
http://sohne.net/files/semafox:
application/pdf:
semapedia.pdf: Semapedia in Africa
application/octet-stream:
semacoder-0.47.dmg: Semacoder 0.47 (Mac OS X)
Inside the page that I have designated as my assets page by setting
the ‘Asset List’ behavior, I can put in tags that will filter my
assets by content type, or by host, or both, and use that to list the
assets that match the conditions.
Visiting my asset page will then give me a list of all my PDF
documents regardless of the actual asset location. In addition, the
Asset List behavior will automatically transform all child URLs that
match the asset key (e.g semapedia.pdf).
In addition to the above behavior, which is really just a convenient
way to list your site assets, you can access URLs such as (my asset
list page is /assets)
http://sohne.net/assets/semapedia.pdf
and you will be automatically redirected to the actual content. The
system doesn’t handle duplicate asset keys, only taking the first one
that it gets. I think this is a GOOD THING, to have one key per
resource.
I’ve placed the code in a Subversion repository accessible via
svn+ssh://sohne.net/users/home/guido/svn/assets_behavior
and you can check it out with
svn co
svn+ssh://sohne.net/users/home/guido/svn/assets_behavior/trunk/assets_behavior
I’m not sure if anonymous access to my repository is working yet so
I’ve added a tarball to my assets available via
http://sohne.net/assets/assets_behavior-0.0.1.tar.gz
I hope this is useful and I had fun writing and learning about Radiant
behaviors. My only regret is that behavior is not spelt behaviour
since this led to a lot of grief for me (my muscle memory is
intimately hooked up with behaviour).
Question: I am memoizing the YAML parse and I need to invalidate it
when the ‘assets’ page part is updated. How do I do this?
– G.