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.
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="">
we talked about this last night and it sounds pretty good this
morning too with a
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
