You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Juergen Donnerstag (JIRA)" <ji...@apache.org> on 2008/12/27 14:41:44 UTC
[jira] Created: (WICKET-1996) Rework PackageResource and
ResourceReferences
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-M1
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.
[jira] Commented: (WICKET-1996) Rework PackageResource and
ResourceReferences
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901438#action_12901438 ]
Igor Vaynberg commented on WICKET-1996:
---------------------------------------
Juergen, how is the rewritten code in 1.5 compare to this? have we addressed this and so should we close this?
> 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.
[jira] Assigned: (WICKET-1996) Rework PackageResource and
ResourceReferences
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg reassigned WICKET-1996:
-------------------------------------
Assignee: Juergen Donnerstag
assigning to Juergen so he can evaluate the current state against these requirements.
> 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
> Assignee: 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.
[jira] Updated: (WICKET-1996) Rework PackageResource and
ResourceReferences
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-1996:
----------------------------------
Fix Version/s: 1.5-M3
(was: 1.5-M2)
> 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
> Assignee: Juergen Donnerstag
> Fix For: 1.5-M3
>
> 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.
[jira] Issue Comment Edited: (WICKET-1996) Rework PackageResource
and ResourceReferences
Posted by "Sven Ludwig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901403#action_12901403 ]
Sven Ludwig edited comment on WICKET-1996 at 8/23/10 10:35 AM:
---------------------------------------------------------------
I discovered a problem with the ResourceReference today that should be considered in the rework with respect to the new structure. The javadoc of the central method getResource() states in 1.4.9: "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. But there is no code to determine the Resource anew after a serialization/deserialization occurred, and this seems to me like a problem/bug.
Does that mean that a ResourceReference in 1.4 was never intended to be stored as a member variable in a Component? Does the developer always indeed have to create a new ResourceReference (and possibly bind it) to access the referenced Resource securely?
was (Author: sludwig):
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.
[jira] Commented: (WICKET-1996) Rework PackageResource and
ResourceReferences
Posted by "Sven Ludwig (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WICKET-1996) Rework PackageResource and
ResourceReferences
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903981#action_12903981 ]
Hudson commented on WICKET-1996:
--------------------------------
Integrated in Apache Wicket 1.5.x #275 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/275/])
Started to javadoc ResourceReference and friends
WICKET-1996
Issue: WICKET-1996
> 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
> Assignee: 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.
[jira] Updated: (WICKET-1996) Rework PackageResource and
ResourceReferences
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-1996:
----------------------------------
Fix Version/s: 1.5-M2
(was: 1.5-M1)
> 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.
[jira] Updated: (WICKET-1996) Rework PackageResource and
ResourceReferences
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson updated WICKET-1996:
-------------------------------------
Fix Version/s: (was: 1.5-M3)
1.5-M4
> 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
> Assignee: Juergen Donnerstag
> Fix For: 1.5-M4
>
> 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.
[jira] Updated: (WICKET-1996) Rework PackageResource and
ResourceReferences
Posted by "Juergen Donnerstag (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Juergen Donnerstag updated WICKET-1996:
---------------------------------------
Attachment: wicket-1996.patch
This is a first attempt which does not yet remove ResourceReferences. But when you look at the code and how little value ResourceReference provides it may become more obvious that it can be removed.
Note that this patch is not a "apply and go" patch. It is a first draft.
> 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-M1
>
> 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.