What I meant with 'not too hard' is that we could probably just use the URL class to figure out the jar://, file:// etc protocols; it'll come for free. I am not an expert on classloading stuff though, so I'm not sure about any catches here.
If I were to do it now, I would base it on the code you put in Wicket for the sharing of images. I think I would let a resource register itself (e.g. in its constructor) as a shared resource, and then make components like Image smart enough to figure out that if they have a resource set (as the model?), the reference to that resource should be used as the url.
Am I on the right track?
Eelco
Jonathan Locke wrote:
maybe not too hard, but do you want to write this by the end of the week?
we need to ship this thing and more features won't help! ;-)
Eelco Hillenius wrote:
Jonathan Locke wrote:
okay, i think i've got it... see below.
Eelco Hillenius wrote:
A short note about what I think the requirements for packaged (image) resources are.
The way resources are currently implemented work fine for the cases where there is a one-to-one relation between the resource and the component that uses it (i.e. it is the same thing). However, to make packaged resources really usefull, these issues should be addressed:
1. It should be easy to get them from any package wanted (currently at least for images, only the current package can be used, so to get a component from a certain package, first a component must be created in that package).
you meant "to get an image from a certain package", i think.
there is a TODO in the Image class about this. we should allow at least relative paths like images/foo.gif or ../images/foo.gif. i'm not sure about absolute paths. would that mean /com/mycompany/images/foo.gif? could the user do /images/foo.gif too? guess that might make sense as far as jar files go, but we'd have to implement differently if it's not in the package structure... what about just allowing relative paths for now? (nothing starting with /)
Yep, I noticed the TODO. I was thinking about a path starting with a / working just like looking up a resource from the class loader. Maybe that's not a good idea here. One thing we might consider, is to support complete URL's like file:// and jar:// etc. How about that? Wouldn't be too hard too implement too I think...
2. It should be possible to use static (global/ session) resources. Currently, there is a one-on-one relation between resource and component. So, even if the component is marked to be reusable (using setSharing), a new resource url is registered for each instance.we talked about this last night and it sounds pretty good this morning too with a
So, what I'd like to do basically is to be able to create components that have their own identity (and their own panels etc), but that use a shared resource for specific things. This could look like:
ImageResource res = new ImageResource("/mypkg/myimg.jpg"); // to be globally registered, and does the lookup/ rendering of the image
res.setSharing(APPLICATION_SHARED);
Image img = new Image("component1", res);
add(img);
...
<img id="wicket-component1" src="">
few adjustments.
i'm having a problem with you specifying a url in Java. i'm not so sure about that. the url should come from the SRC attribute of the IMG as before.
<img id = "wicket-image1" src = "myimg.jpg"/>
only now the thing you're calling ImageResource would get created automatically.
so basically every static image would have two parts, the normal image component
as it exists now and the resource part which would be cached in a global sense
based on the url. make sense? it just works. totally simple, maintains current
functionality. "sharing" is based on the actual URL.
i'd eliminate sharing altogether. it's a bad concept that can be simpler and just as secure.
Yep, I had the same thoughts. If we seperate the component and the resource part, the kind of sharing would be totally in control of the user that wants to use it.
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
