User "Brion VIBBER" posted a comment on MediaWiki.r89918. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89918#c18008 Commit summary:
Use FileAPI for previews when possible. This complicates the situation of when a thumbnail may be generated. Depending on config or layout, it could be any of: 1) Thumbnail wanted before ready 2) Thumbnail wanted after ready multiplied by 1) FileAPI, locally scaled 2) Stashed Image API, remotely scaled, with exponential backoff retries 3) Image API, remotely scaled, with exponential backoff retries And of course all the error conditions! So, I have moved to a different model for obtaining thumbnails, where you just declare that a certain HTML element needs a thumbnail with setThumbnail(), and the framework figures out what it's supposed to do, and the thumbnail should show up eventually (or finally give you a broken image and an error condition). The thumbnail framework is now using a pub/sub model with a twist; certain events can happen only once, and you can subscribe to them in the past. This is a little bit like the 'ready' state of some DOM elements, so these are called by 'publishReady' and 'subscribeReady'. Think of it as "publish that we are now ready to show this thumbnail" or "do this action when the thumbnail is ready (or right away if it already is)". Comment: IMO showing an incorrectly rotated preview thumbnail is a regression; if I disable the fileApi support, I see a correctly-oriented thumbnail after upload, which carries through the remaining steps of the process. If I leave it on, I see an incorrectly-oriented thumbnail all the way through the process, until I arrive on the actual File page afterwards and discover it's been rotated back into place. _______________________________________________ MediaWiki-CodeReview mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
