i think we should delay this feature to 1.1
Eelco Hillenius wrote:
I could try, but I probably won't have time until saterday, and sunday
I have several appointements.
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.
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
-------------------------------------------------------
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
