- If `source` is defined then register source group immediately
- If `source` is not defined then create a signal handler and attach it to
`class_prepared` signal which will see if there is only one ImageField in
the given model.
This will fix problems coused in Python 3 about using ImageSpecField
without providing a `source`.
Changed my mind about 04aa72c1f9. It's
just a better description, even if different strategies can change the
behavior so it isn't really very cache-like.
This allows a sensible specialized interface for source groups, but also
for ImageKit to interact with specs using the generalized image
generator interface.
Everything for dealing with files should be part of
GeneratedImageCacheFile--not the generator. The fact that
GeneratedImageCacheFile can get this information (storage, filename,
etc.) is a convenience so that the user only has to define one class
(the generator) to fully specify their functionality, but handling the
cache file is not part of the core responsibility of the generator.
This is also the reason for the renaming of `get_filename` and `storage`
to `cache_file_name` and `cache_file_storage`: the generator is just as
useful for those who want to generate persistent files. But the original
attribute names didn't indicate that they were used only for cache
files. The new ones do, and don't preclude the addition of other
versions that would be used by another `File` subclass for specifying
file names or storage classes.
Previously, we had two places where we were passing kwargs that affected
the image generation: the ImageSpec constructor and the generate method.
These were essentially partial applications. With this commit, there's
only one partial application (when the spec is instantiated), and the
generate method is called without arguments. Therefore, specs can now
be treated as generic generators whose constructors just happen to
accept a source_file.
The registry module splits the work that specs.SpecRegistry
used to do into two classes: GeneratorRegistry and
SourceGroupRegistry. These two registries are wrapped in
Register and Unregister utilities for API convenience.
The registry's `get_spec()` was already supporting kwargs as a means to
provide information about the source to the spec constructor/factory
function, but the ``SpecHost`` class wasn't capable of accepting any.
This commit rectifies that. The main goal purpose of this is to allow a
bound field (the file attached by ``ImageSpecFileDescriptor``)--and the
attached model instance--to be taken into account during the spec
instance creation.
Related: #156
This marks a major step towards centralizing some of the "spec" logic
and creating a single access point for them. Because `ImageSpecFields`
are just alternative interfaces for defining and registering specs,
they can be accessed and overridden in the same manner as other specs
(like those used by template tags): via the spec registry.
Somewhere along the line, a change got merged that stopped using the
receivers module. This re-integrates it and moves changes made to the
old receivers (static methods on ImageSpecField) to them.
This new feature gives the user more control over *when* their images
are validated. Image cache backends are now exclusively for controlling
the *how*. This means you won't have to write a lot of code when you
just want to change one or the other.
While this change means users can no longer specify their own filenames,
changing a property of a processor, for example, will now result in a
new image. This solves a lot of the previous invalidation issues.
