Eelco Hillenius wrote:
I'll do. One more thing: I though to solve the tree images by including static images. That was stupid, because it introduced concurrency problems, and was generally not right, as every image needs to be a real component instance with a unique etc.
So, I fixed that now, but with a bit of a hack.
Basically, this is my problem: I just have a few different images, that are reused within the tree quite often. Instead having a different url for them all, they should really point to the same image. I solved this by declaring the images I want as static variables, setting their sharing to application level, and then using the url's to these component with the real image components, like:
String url = getRequestCycle().urlFor(JUNCTION_IMG_BLANK, IResourceListener.class);
the urls will automatically be stable if you set sharing on your images to APPLICATION_SHARED. or did i miss your point?
Naturally, this is not a very elegant solution. But... I can't think of a better way to do this currently.
aaaah! you're right about component sharing. it seems like it might be totally busted...
but it works great in my trivial test with one shared component! ;-)
the /parent/ field can't be shared like this, but then it's never going to be used by a simple resource component except maybe if the resource requires a localized string. but then it could use application. am i making sense? in other words, if it's just parent that's the problem, maybe AbstractImage should extend AbstractResourceComponent or something (which i'm already thinking we need... but haven't thought this out). the implementation of getParent() in this base class would simply throw a WicketRuntimeException if sharing was turned on saying "this component doesn't have a parent".
if something like this isn't possible, i'm wondering if the whole static/singleton component idea is just broken. maybe the big deal is actually not that we save on components, but that we don't serve up the same image from different urls, right? so the other option is that maybe we don't ever make resource components static/singleton, but rather make it so that instances of them can indicate that they serve the same resource... the obvious way to do this is to use the component's class and the name of the resource it's referencing to build a synthetic url.
thoughts?
Btw, I looked a bit a the browser's behaviour. It really seems that the default behaviour is fine (the browser regconizes that is has some images allready), so I think cachability is nice as it is without tinkering with response cache headers...
hmm... okay, perhaps that's right...
Eelco
Jonathan Locke wrote:
can you bug this against me? this is something we have to fix for 1.0.
thanks,
jon
Eelco Hillenius wrote:
As there is getPage().getClass(), it will allways look for resources relative to the package where the current page is in, which is not right I think. For one thing, I had to hack a bit for the tree to be able to include images from the same package as where the tree is in.
ugh. right. i need to think about this one a bit...
one thing that pops in my head is that this logic doesn't belong in getResource(). it might instead call a method getResourcePath(String resourcePath), passing in the resourcePath from the src tag.
but i think there's more to it...
It's a nasty one.
Any idea's how this should be solved best? I though about getParent().getClass(), but that would be very unpredictable.
Btw, has any work been done to set the cache headers of those application/ session scoped resources?
nope. that would be a good idea. when should a shared "dynamic" image expire? maybe use a good default and give the user control here?
I guess the same as session timeout would be a nice default... Johan, do you have a good idea about this one?
Eelco
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
