Document propogation of resized image width/height

[rjmoggach]

I love this:

<img class="img-fluid" src="{{image.image.crop.720x300.url}}"/>

Is it possible to do this somehow:

<img class="img-fluid" src="{{image.image.crop.720x300.url}}" width="{{image.image.crop.720x300.width}}" height="{{image.image.crop.720x300.height}}"/>

Documentation on built-in sizers and filters could be expanded on a bit too... please!

[rjmoggach]

FYI: this pluggable app really is just a bit too awesome. You need to dull it down a bit or start selling it so we can resent you for it. Sooo easy and sooo great.

[respondcreate]

Hey @robmoggach !

First off: thanks for the kind words about this project, I really appreciate it! Returning cropped image width and height is definitely possible but would introduce a non-insignificant performance hit to your application since getting those values would necessitate either...:

1. ...a calculation anytime a cropped rendition is requested (based on the 'master' image width height) or...
2. ...opening the cropped rendition image file from storage to determine its size.

SIDE NOTE: Getting the width/height of a master/original image doesn't incur this same performance hit since those values are only calculated once (when a new image is associated with a field) and then stored in the database (if you define a width_field & height field (relevant docs here)).

If you have a low traffic application with only a few images on a page it wouldn't be that big of a deal but a grid of 20+ thumbnails would start to significantly impact page load.

Whenever a new feature is requested on this application – and I'm weighing whether-or-not I should implement it – I first ask myself if adding it will makes developers lives easier. In this case that's definitely true. However, right afterwards I ask if said feature would incur a significant performance hit. In this case – unfortunately – it does so, for the moment at least, I wouldn't consider adding it to the project.

All that said, if you can figure out a way to get these values with a minimum amount of overhead and want to open a PR, I'd definitely seriously considering merging it into this project!

Also, could you elaborate a bit more about what sort of information your after in regards to this:

Documentation on built-in sizers and filters could be expanded on a bit too... please!

[rjmoggach]

Sounds good. Makes sense.

I think I was referring to examples in templates and how to chain sizers and filters. I found the documentation eventfully but maybe the quick start section could use another example snippet.

On Jul 31, 2016, at 9:11 AM, Jonathan Ellenberger notifications@github.com wrote:

Hey @robmoggach !

First off: thanks for the kind words about this project, I really appreciate it! Returning cropped image width and height is definitely possible but would introduce a non-insignificant performance hit to your application since getting those values would necessitate either...:

...a calculation anytime a cropped rendition is requested (based on the 'master' image width height) or... ...opening the cropped rendition image file from storage to determine its size. SIDE NOTE: Getting the width/height of a master/original image doesn't incur this same performance hit since those values are only calculated once (when a new image is associated with a field) and then stored in the database (if you define a width_field & height field (relevant docs here)).

If you have a low traffic application with only a few images on a page it wouldn't be that big of a deal but a grid of 20+ thumbnails would start to significantly impact page load.

Whenever a new feature is requested on this application – and I'm weighing whether-or-not I should implement it – I first ask myself if adding it will makes developers lives easier. In this case that's definitely true. However, right afterwards I ask if said feature would incur a significant performance hit. In this case – unfortunately – it does so, for the moment at least, I wouldn't consider adding it to the project.

All that said, if you can figure out a way to get these values with a minimum amount of overhead and want to open a PR, I'd definitely seriously considering merging it into this project!

Also, could you elaborate a bit more about what sort of information your after in regards to this:

Documentation on built-in sizers and filters could be expanded on a bit too... please!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.