[
https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901403#action_12901403
]
Sven Ludwig commented on WICKET-1996:
-------------------------------------
I discovered a problem with the ResourceReference today that should be
considered in the rework. The javadoc of the central method getResource()
states: "Gets the resource for this resource reference. If the
ResourceReference has not yet been bound to the application via
bind(Application)this method may return null."
However, the method also returns null if the ResourceReference instance has
gone through serialization/deserialization. The member variable holding the
referenced resource needs to be transient, so far so good. But there is no code
to determine that the Resource instance anew after a
serialization/deserialization occurred, and this seems to me like a problem/bug.
Does that mean that a ResourceReference is never to be stored in a Component?
Does the developer always have to create a new ResourceReference and possibly
bind it to access the referenced Resource?
> Rework PackageResource and ResourceReferences
> ---------------------------------------------
>
> Key: WICKET-1996
> URL: https://issues.apache.org/jira/browse/WICKET-1996
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Juergen Donnerstag
> Fix For: 1.5-M2
>
> Attachments: wicket-1996.patch
>
>
> while working on wicket-1992 and looking at PackageResource and it
> subclasses, and ResourceReference and its subclasses I couldn't stop making
> changes because of code which - I guess - is as it is because of historic
> reasons. E.g. shared resources must be registered which is not longer valid
> since shared resources are now lazily loaded. Below is a list of changes,
> which can not be done to 1.4 since they change behavior and are not fixing
> bug, but they should make into 1.5
> A)
> 1) PackageResouce.get() creates new PackagedResources if not found in the
> shared resources cache. We should either change the name or do not create a
> new resource. Javadoc does not state that a new resource is created.
> 2) Subclasses of PackageResource have copies of the very same method, except
> that they also register the new resource with the shared resources cash.
> Which probably is the correct way if we really want to create new resources
> in a get method.
> 3) There is no way to determine if get() created a new resource or if a new
> resource was created
> 4) Because there is no way for subclasses to create their own resources, e.g.
> JavascriptPackageResource, get() was copied.
> 5) bind() is not much different to get() currently except that bind()
> validates that the new resource exists. If the resource does not exist, an
> exception is thrown. It is no longer obvious which method get() / bind()
> should be used when and what there real purpose is
> In my opinion get() should simply check the cache and nothing more. And get()
> should be made final.
> B)
> I'm not very much in favor of static methods. They carry the risk, if not
> careful, that more than one wicket application can not be deployed without
> interfereing with each other. I'm the last one to consider everything at any
> time. In my opinion we should remove all static methods from PackageResource
> except get() for convience reasons and move the bind() logic into the
> constructor. This makes subclassing PackageResource more easy as well. You
> would simply do
> resource = PackageResource.get().
> if (resource == null)
> {
> resource = new JavascriptPackageResouce(...);
> }
> C)
> I don't think ResouceReference serve any real purpose any more. I would
> remove them all.
> I'll attach my working copy in case you are interested.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
