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 /)
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.
for dynamic images (subclasses of DynamicImage), the ImageResource ought to be
more like your example... separate from the component and /not/ automatically attached.
instead, the scoping of the dynamic image would depend simply on where you put it. if
you put the dynamic image resource in your session, it will have session scope. if you put
it in your application or make it static, it would have application or vm scope. when the
component referencing the resource renders, it will use the unique id assigned to the
ImageResource. to keep things secure, we'll just create a cryptographically secure id like
your session id for the image. this will be a little more pain to debug when it comes to that,
but the use case is vastly simpler and justifies the id.
for example, imagine the current ButtonImage. if you created a ButtonImageResource
called cancelButtonImageResource (probably through a factory method of the ButtonImage
DynamicImage) and put it at application scope, you could create two button image
components that share the resource by simply saying:
new ButtonImage("button1", getMyApplication().getCancelButtonImageResource())
new ButtonImage("button2", getMyApplication().getCancelButtonImageResource())
totally simple. to scope something by session, you'd just make it a session property:
new ButtonImage("button1", getMySession().getCancelButtonImageResource())
new ButtonImage("button2", getMySession().getCancelButtonImageResource())From this follows that the resource is not a component in the sense that it can be/ has to be placed in a page. Rather, resources can be used completly on itself. The resource could lookup whether a similar resource allready was registered (e.g. resource could override equals, or have a specific kind of equals-like method for this).
Any ideas/ opinions?
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
