Problem/Motivation
Follow-up from #2211227: Refactor image and imagetoolkit: isExisting, isSupported, supportedTypes, getMimeType.
In the above mentioned issue, we discussed and decided that passing around an image parameter to calls to a toolkit is useless.
Why? Because a toolkit instance is linked to exactly 1 Image object, passing around that object seems not correct. Better would be to pass it to the constructor. However, this is not possible as the toolkit object is created just before the image object, as we also need to pass the toolkit object to the Image constructor.
Proposed resolution
Instead of passing the Image to the methods (as now) or to the constructor (which is not possible), we create a property and (public) setter/getter for the ImageInterface object in toolkit that should be called by the constructor of the Image class. A 2nd call to that setter is not expected and thus should fail with an exception.
In addition to this basic part of the issue, the currently RTBC'd patch:
- streamlines some documentation in involved classes.
- declares a not yet declared but used property in a test class ($source in ImageTest.php).
Remaining tasks
Commit patch.
User interface changes
None.
API changes
The signature of several methods will change. This will be documented in the Change record that documents the new Image API.
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | interdiff.txt | 636 bytes | fietserwin |
| #20 | 2257587-20.patch | 32.86 KB | fietserwin |
| #18 | 2257587-18.patch | 32.86 KB | fietserwin |
Comments
Comment #1
fietserwinComment #2
fietserwinPatch is built on top of parent issue #2211227: Refactor image and imagetoolkit: isExisting, isSupported, supportedTypes, getMimeType and is for the test bot, the interdiff is the patch for this issue and is thus for manual review.
Comment #4
fietserwinWe are testing order and position of parameters in 3 places:
- unit test \Drupal\Tests\Core\Image\ImageTest (that was already adapted in the patch of #2)
- webtest \Drupal\image\Tests\ImageEffectsTest (corrected here)
- webtest \Drupal\system\Tests\Image\ToolkitTest (corrected here)
This does need some clean up, especially the latter 2 seem to test very similar things.
The patch is, as in #2, a combination of patch for the parent issue and this issue and is for the test bot, the interdiff is the patch for this issue and is thus for manual review (and is thus not the interdiff between #2 and #4, that's not interesting and nobody had already reviewed #2 (I think)).
Comment #5
fietserwinComment #6
mondrakeReview of interdiff code in #4
The @throws description should be a separate line, see the coding standards.
Also, I see @throws is usually after the @param/@return blocks. I don't know if it matters though.
You don't need
usefor root classes, just call \BadMethodCallException with backslash in the code. OTOH, how about introducing a specific ImageToolkitException here? There's one waiting in #2122605-18: Remove isAvailable() from ImageToolkitInterface.Same here
This could go to the ImageToolkitBase? I am expecting this to be same in all toolkits, and GDToolkit and TestToolkit already extend from ImageToolkitBase.
One full stop too much ;)
Full stop at the end of text?
Comment #7
mondrakeComment #8
fietserwinThanks for reviewing. All points done, except the introduction of our own exception. Let's postpone that to the mentioned issue.
As before:
-.patch is for test bot (combined patch)
- interdiff.txt is for manual review
- interdiff4-8.txt is some kind of interdiff between the interdffs of #4 and #8. [EDIT: but I failed to create it properly. In fact, I moved the property, getter and setter from GD to base toolkit including any use statements]
Comment #9
mondrakeLeftover, it's in the parent class now
Same
I suppose it can be removed here too, now?
Comment #10
mondrakeSorry, couple more minor things
Let's keep this blank line.
Just to check, this is because setUp() is setting this property but it was not declared in the class, right?
Comment #11
fietserwinThanks, all corrected, I was a bit too fast with posting the new patch and forgot the test class. And yes you are right (PHPStorm complained about it and (AFAIK) in Drupal we do declare properties explicitly).
You probably also noticed that:
- I also streamlined some documentation in this patch.
- In ImageTest, I had to create new toolkit instances, if not the default image was used in the test. Thus properties image and toolkit of that class are linked together and cannot be reused without the other (setImage() will throw).
(For the core committer, I will update the summary with this info as well)
(More or less) As before:
- .patch is for test bot (combined patch).
- interdiff-11.txt is for manual review (patch for this issue only on top of parent issue patch).
Comment #12
mondrakeSeems OK now, we need to wait for the parent to get in first.
Comment #13
fietserwinRTBC per #12 and comment #26 of the parent issue: #2211227-26: Refactor image and imagetoolkit: isExisting, isSupported, supportedTypes, getMimeType.
- This patch is a combination of the parent issue and this issue.
- The interdiff is the "patch" for this issue only.
Comment #14
tim.plunkettWhy is this desirable? Why would we *choose* to make the toolkit stateful?
Comment #15
fietserwinAn image is strictly tied to 1 toolkit: we cannot change toolkit halfway processing an image style.
Vice versa, 1 toolkit is tied to 1 image. This because Image holds the source, but (GD)Toolkit holds the (GD) resource based on that source and subsequent manipulations. so there is state in toolkit that Image depends on and that Image does not have itself. Though this tie may not be so strict, a toolkit object could be reused when it is finished with 1 Image, but we chose to not do so and always create a new toolkit object together with an Image object. In practice this won't be a problem, as Images (and their toolkits) are created via the factory, but a few tests indeed did reuse a toolkit object.
(In fact, what we see here is a (1 of many) code smell that tells us that toolkit and image should be unified in 1 class/interface/factory. Time permitting, we might end up doing that yet in D8.)
Comment #16
fietserwinReroll after reroll of #2211227: Refactor image and imagetoolkit: isExisting, isSupported, supportedTypes, getMimeType which was needed after #375062: imagecolorsforindex() Color index nnn out of range in GDToolkit.
As before:
- .patch is for both issues at the same time
- interdiff-16.txt is only for this issue (and thus not an interdiff with #11)
Comment #17
xjmCan we edit https://drupal.org/node/2084547 to add a reference to this issue? That way, the CR can document the work in progress and will appear in the sidebar of this node.
Also, this and that shouldn't both be RTBC at the same time. This seriously confused me. :P .Postponing on #2211227: Refactor image and imagetoolkit: isExisting, isSupported, supportedTypes, getMimeType.
Comment #18
fietserwin#2211227: Refactor image and imagetoolkit: isExisting, isSupported, supportedTypes, getMimeType is in, so the interdiff now becomes the patch. Had to change some paths in it though.
Comment #19
mondrakeVery minor, but let's fix it anyway :)
TRUE and FALSE (capital letters)
Comment #20
fietserwinfixed that minor.
Comment #21
mondrakeGood to go for me. Nice cleanup. RTBC
Comment #22
catchCommitted/pushed to 8.x, thanks!