I wanted to try and gather some feedback on ideas for extending it, to make it even more useful.
Things that have been mentioned are for example a way to use the alt attribute. Others have mentioned the width/height attributes. So in general, I am thinking that it might be interresting to do something generic for attributes?
The first thing that I've thought, is doing something like this:
I just had a chance to try the new umbraco:image control. Very cool. I think improvements like this is really important, small as it may seem. But it just seems wrong to create a macro to render a image and I am not a big fan of inline macros. This is cool.
I do have two comments.
It would be great if to be able to append a string to the rendered image src. I use the ImageResizer asp.net component and that takes a set of querystrings a bit like ImageGen. I realise that I could write a new provider for it, and maybe that's the way to go.
If no image is found (maybe I passed an empty string) then I don't think the img tag should be rendered.
Regarding the src, yes I think the provider would be the "right" way to go, but I do see the point in it maybe being too difficult for some to do. Would it make sense to do something like this:
Then the {0} would be replaced with whatever the selected provider returns?
I see your point about hiding the image if the field is empty. or maybe only if the provider returns an empty string. I could be that the provider has a fallback image that it uses as a default. My only concern is that nothing is rendered at all, which might confuse the developer a bit? But it is probably the right way to go, as there is no other was to do it really.
Regarding the special [#xxx] syntax - I like the idea, but I think it's conflicting a little bit with the Advanced Macro Parameter Syntax? I'd expect [#title] to be grabbed from $currentPage/title and not the media item. It would be great if the image control could (at some point) support the usual symbols, so we should probably have another symbol here - I vote for § or ~ :-)
Yes that was pretty much what I was thinking, with appending parameteres to the image url. Of course creating a provider is more elegant, but I think most of these image components take a set of parameters in the form of a querystring anyways. Not as elegant, but a bit easier ;)
If you had the option to show an alternative image, or just nothing, then that might solve the problem, when no image is found. That sounds like a nice solution.
I see your point. Also, there is to possibility that there is not actually a media item, but the rendered field could be an upload datatype, that just gives a path to the image. So in that scenario, the fields would need to be fetched from the page, and not the media item.
I hadn't seen Damian's post, but I'd be happy to look into the options. The thing is, that razor is much more flexible with how you get an image, but could you maybe provide a small sample of how you would like your code to look, when using this in razor? Is it the provider part that you would like, or is it the logic for fetchin the image path?
Argh, while reading I found out that I misunderstood something and this is actually not what I really need.
I only need the resizing-part of the image, not the referencing to an image that already has been resized or setting width and height properties of the html tag. Sorry for making a fuzz :D
With the new umbraco 6, where MVC/razor is well integrated, there is no longer a need for the image control, as I see it, because it is so easy to get the image url with the new api's.
Ideas for the umbraco:image control
Hi all
As some of you may have seen, umbraco 4.11 ships with a new control, the umbraco:image control. Read more about it here: http://24days.in/umbraco/2012/introducing-the-umbraco-image-control/
I wanted to try and gather some feedback on ideas for extending it, to make it even more useful.
Things that have been mentioned are for example a way to use the alt attribute. Others have mentioned the width/height attributes. So in general, I am thinking that it might be interresting to do something generic for attributes?
The first thing that I've thought, is doing something like this:
This would the understand that attributes that have the [#] syntax are to be retrieved from the properties of the media item that is being rendered.
Would that be a nice way to do it? If the attribute does not contain [#], then it will just be written raw to the output.
Any other ideas/suggestions that you would find useful when using the control?
Hmm, maybe I should bump this back up after the holidays :-)
Hi Morten,
I just had a chance to try the new umbraco:image control. Very cool. I think improvements like this is really important, small as it may seem. But it just seems wrong to create a macro to render a image and I am not a big fan of inline macros. This is cool.
I do have two comments.
But I think its awesome :)
Cheers
Bjørn
Hi Bjørn. Thanks for the feedback.
Regarding the src, yes I think the provider would be the "right" way to go, but I do see the point in it maybe being too difficult for some to do. Would it make sense to do something like this:
Then the {0} would be replaced with whatever the selected provider returns?
I see your point about hiding the image if the field is empty. or maybe only if the provider returns an empty string. I could be that the provider has a fallback image that it uses as a default. My only concern is that nothing is rendered at all, which might confuse the developer a bit? But it is probably the right way to go, as there is no other was to do it really.
Hi Morten,
Regarding the special [#xxx] syntax - I like the idea, but I think it's conflicting a little bit with the Advanced Macro Parameter Syntax? I'd expect [#title] to be grabbed from $currentPage/title and not the media item. It would be great if the image control could (at some point) support the usual symbols, so we should probably have another symbol here - I vote for § or ~ :-)
/Chriztian
Hi Morten,
Yes that was pretty much what I was thinking, with appending parameteres to the image url. Of course creating a provider is more elegant, but I think most of these image components take a set of parameters in the form of a querystring anyways. Not as elegant, but a bit easier ;)
If you had the option to show an alternative image, or just nothing, then that might solve the problem, when no image is found. That sounds like a nice solution.
Cheers and happy New Year :)
Bjørn
Hi Chriztian
I see your point. Also, there is to possibility that there is not actually a media item, but the rendered field could be an upload datatype, that just gives a path to the image. So in that scenario, the fields would need to be fetched from the page, and not the media item.
/Bock
Hi
Is there a way/version to get this to work in an mvc view in v6?
Damian
Sorry for warming this up again. But I'm currently having the same question Damian asked a few months ago.
Would be awesome to have this in Razor..
I hadn't seen Damian's post, but I'd be happy to look into the options. The thing is, that razor is much more flexible with how you get an image, but could you maybe provide a small sample of how you would like your code to look, when using this in razor? Is it the provider part that you would like, or is it the logic for fetchin the image path?
Argh, while reading I found out that I misunderstood something and this is actually not what I really need.
I only need the resizing-part of the image, not the referencing to an image that already has been resized or setting width and height properties of the html tag. Sorry for making a fuzz :D
Remember resizing in html will still mean fetching back the full sized image first...
I had started looking at the WebImage stuff and posted a little starter up:
http://our.umbraco.org/projects/starter-kits/standard-website-mvc/bugs-issues/36039-How-about-add-WebImage-helper-example-code-to-this-package
What's the latest with Umbraco:Image,
It's a bit useless if you can't pass the Alt/Description on to the tag.
p.s it's cool! and i'd like to use it :D
Hi Laurence
With the new umbraco 6, where MVC/razor is well integrated, there is no longer a need for the image control, as I see it, because it is so easy to get the image url with the new api's.
is working on a reply...