Drupal Association members fund grants that make connections all over the world.
Updated: Comment #22
This issue is a spin off of issue, more specifically comment #71 ( ).
In that issue we discovered that it is difficult/impossible to cleanly add toolkit specific code for new image effects. On working towards a solution we found that defining a new toolkit (e.g. Imagemagick toolkit) is also going to be hard with the current design.
This issue focuses on making it more easy/logical to implement an ImageToolkit in contrib.
- Image/ImageInterface: define a GD resource handle and methods getResource(), setResource(), hasResource(). These are in fact GD specific and will only be ballast for other toolkits. (What should an imagemagick toolkit return in hasResource()?)
- Contrib toolkits will not use a GD resource, but will have their own data to store. Where to store this:
- In image: iin PHP it is technically possible to add your own properties, but this is not considered a good practice.
- In toolkit instance: this will tie a toolkit instance to a specific Image instance but allows contrib toolkits to add properties as needed.
- In their own newly defined MyImage class: the image factory from core is not made up to this task, so this will be difficult to implement.
We chose to go for the 2nd option above: tie toolkit instances to specific Image instances, so a toolkit can store all data it needs in its own object.
Concrete changes this patch implements:
- move the resource handle from the image class to the GDToolkit plugin.
- move Image::getResource() and Image::setResource() to the GDToolkit as well.
- drop Image::hasResource() and replace with an Image::isExisting() method that will just return if an image is existing and 'manageable' for the toolkit.
- the ImageFactory creates a new instance of the toolkit when creating a new image. This is because in this approach each Image instance will get a separate toolkit instance, so that image specific information managed by the toolkit can be stored at toolkit level. ImageFactory is receiving the toolkit manager in the constructor then, no longer the toolkit itself, and we no longer need 'image.toolkit' as a service.
setToolkit()method in the ImageFactory is replaced by a
setToolkitId()method, as the ImageFactory no longer needs to store an instance of the toolkit. Every Image will get its own toolkit instance. Also, the ImageToolkitManager has a new
getDefaultToolkitId()method to respond to ImageFactory request for the ID of the default toolkit plugin.
- Image has also an Image::getToolkit() method to retrieve the toolkit object stored in the Image instance. That is needed to enable tests and to allow access to the toolkit object by contrib code.
- the load() method in the GDtoolkit becomes an internal protected method to the GDtoolkit.
- Review patch.
- Write change notice. (Update current change notice?)
User interface changes
None, this is pure DX.
Image system will be changed. As this is already completely different from D7, and image related contrib maintainers actively participate in these issues, that should not be a problem.
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 65,084 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 64,893 pass(es). View