Here are some thoughts after working with PackageResourceReference.
The IModel interface is really great. It makes no assumptions about
where things are coming from. I can even install an IModel instance I
create on the fly, just overriding IModel.getObject() (and a couple of
other methods).
I am listing files in a DataView. I want each file to have an icon,
loaded from resources. The actual icon depends on the file. Here are two
example icons:
final PackageResourceReference fooIconResourceReference = new
PackageResourceReference(Foo.class, "foo-icon.png");
final PackageResourceReference barIconResourceReference = new
PackageResourceReference(Bar.class, "bar-icon.png");
In my DataVIew I'd like the actual icon to be determined at retrieval
time, whether "foo-icon.png" or "bar-icon.png", based upon
FileItem.isBar(), like this:
item.add(new Image("icon", new IPackageResourceReference() {
@Override
public PackageResource getResource() {
if(item.getModelObject().isBar()) {
return barIconResourceReference.getResource();
} else {
return fooIconResourceReference.getResource();
}
}
}));
See, if there was some general IPackageResourceReference interface
(analogous to IModel), I could simply override its getResource() method
and delegate to already-constructed package resource reference instance.
Or even better, if there was a general resource reference interface,
then I could just override getResourceReference() and return
fooIconResourceReference or barIconResourceReference.
But this won't work as it currently stands, because the
PackageResourceReference class makes all sorts of assumptions about how
the information would be retrieved. I suppose I could pass dummy
variables to its constructor, since I'm going to completely override its
getResource() method, but that simply underscores the need for some
general interface I could override directly.
You might ask why I just don't check my item's isBar() method up front,
and install the correct package resource reference in the image to begin
with. The answer is that I want the icon to be determined dynamically at
render time, not once when the data view is created (and perhaps not
altered for a while, even though file attributes may have changed).
I'm working around it. I just thought I'd pass this thought along as
input on future changes to Wicket.
Garret
