Is it so expensive to register the resources in the constructor? Did
someone profit this? I'm simply saying that I have a feeling this isn't
a problem performance-wise and regarding having at most one instance per
class, why not use something similar to the singleton design pattern?
That is, declare a single static variable which indicates whether the
resources are already initialized or not.
Gili
Johan Compagner wrote:
i am a bit out of idea's so i hope others have a some idea's
first the problem:
StaticResourceReference() did (or does) a bind() call in its constructor.
This will add the underlying resource to the SharedResources for a
specific application object
that is currently in the request cycle.
But because of that you can't use static references to it like this:
private static StaticResourceReference MY_IMAGE = new
StaticResourceReference("xxxxx");
2 problems can happen.
1> If that class is loaded without a RequestCycle object
(if for example it is deserialized by the container) there is no
Application object and a null pointer will happen.
2> it will only bind to 1 application object. Not if there are more then
one.
So i moved the bind to the getPath() method of ResourceReference
This does both problems IF the static resource is used somewhere that is
calling getPath() on it.
If you just do this:
// register dependencies
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/active-bg.gif");
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/dark-bg.gif");
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/hover-bg.gif");
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/menuarrow.gif");
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/normal-bg.gif");
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/rowhover-bg.gif");
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/status-bg.gif");
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/title-bg.gif");
new StaticResourceReference(DatePickerSettings.class,
"style/aqua/today-bg.gif");
And the url is somewhere already in the html side. So for these things
if i remove bind() from the constructor
the resource is never added to the SharedResources..
So i could let the bind also happen in the constructor and make sure
that the application object is there....
(if it is not what to do then? Throw an error?)
But then i still have another problem. If you don't do those things
above in a static block but in a getXXX() method
that is called in the constructor (see for example the DatePicker) then
when we serialize the page and deserialize it again
those X StaticResourceReferences are not made again. Because they aren't
referenced any where in a session
They are just added through the bind() method in there constructor to
the SharedResources
But the constructor isn't called when a DatePicker is deserialized
because the DatePickers constructor is not called.
So first how are we going to instantiate all those
StaticResourceReference that are made as above?
if we said you have to keep a reference to it. (so DatePickerSettings
instance would hold a reference to all those when he makes them)
Then they will be deserialized. But then they will still not be added to
the SharedResources object (from all the wicket applications that
could be running in the current webapplication)
As far as i can see i only see one solution:
Make SharedResources completely static.
(So over all application objects within one WebApplication, but this is
not a big problem because i don't think people will have that)
Then StaticResourceReferences have to really bind once.(in its
constructor). They can be used as in a static way.
And when the get deserialized i can implement the readObject() method of
Serializeable and let the system do its reading in
but also add the resource back to the SharedResources
I hope it is a bit clear, it is a long story :(
but any other idea's?
johan
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
