How does it work?
At the core of Dragonfly is the Dragonfly app
This is configured using
See Configuration for more details.
Normally you will just need the default Dragonfly app, but if you wish you can have multiple apps, each with its own configuration, by giving each a name, e.g.
An app comprises of the following:
- a datastore for storing content and metadata
- any number of processors for modifying content
- any number of generators for creating content
- any number of analysers for analysing content
- a Rack server object for serving content
We can store content with
my_content can be a
Tempfile (or something that responds to
A Job object represents a chained sequence of commands, e.g.
represents the steps
- fetch the content with uid “2008/dog.png” from the datastore
- process this content with the registered “thumb” processor
We can get a url for this job with
The commands “fetch the content then process with the thumb processor” are encoded into this url.
The Dragonfly app is itself a Rack app. When we visit it with this url, we get the fetched and processed content!!
Using the content
is lazy, i.e. it hasn’t actually done any fetching or processing yet.
We can force it to do it using
but we normally won’t need to, because any methods that need the resultant content call
apply behind the scenes. Examples are:
Types of Job Step
fetches the content (and metadata) stored against uid “2008/dog.png” from the app’s datastore.
reads the file “public/sausage.gif” from the local filesystem.
gets the content with a GET request from the given url.
generates content using one of the registered generators.
Each registered processor adds its own method to Job objects
In this example both
rotate are registered processors.
Models for maintaining uids
Typically, models are used to keep tabs on data store uids.
For a model with
image_uid equal to
is equivalent to
See Models for more details.