there is no problem that i'm aware of. you cannot do either of these things:

- hold a PackageResourceReference (or any other wicket object, really) in a static field and expect it to work in a web container that's running multiple applications

- expect a PackageResourceReference to result in a resource that is retrievable before the page that uses it has been rendered

if you want an image that is available from the time your application starts, you MUST store that resource in ApplicationSettings.getSharedResources() using one of the add(...) methods. this has NOTHING to do with ResourceReferences. it has to do with resources. in the ImagesApplication example, this line:

getSharedResources().add("cancelButton", new DefaultButtonImageResource("Cancel"));

makes a dynamic button image resource available at this url:

   http://localhost:8080/images/resources/application/cancelButton

the application shared resources object is a repository of Resources which can come from anywhere that are available through requests to the application outside of any page context.

if you want to have a PackageResource (which is just an image loaded from a given java package), you would write this:

getSharedResource().add("duke", PackageResource.get(MyClass.class, "images/duke.gif"));

after executing this line in your application's initialization, the duke image will be available here:

   http://localhost:8080/<app>/resources/application/duke

you don't USE a resource reference to make something global for all time. a resource reference is the thing that you use to reference a resource from a component. the confusing thing is probably that resource references will bind a resource to the application when they're accessed. but that's being done to make the resource cacheable and expose it at a constant url, not to make it a globally static resource for all time. to do that, you add the resource to the application's SharedResources. make sense now?

Johan Compagner wrote:

i will look into/do paging this week

I am still not there yet what we should do with StaticResourceReferences .... (rename is fine by me, but that still doesn't fix the problems we have with them)

johan

Jonathan Locke wrote:


three new bugs opened that i think really must get fixed for 1.1.

two things to vote on:

1. #1256079 - i'd like to volunteer to do the refactor of the feedback stuff based on the bug i just submitted based on the wicket-user discussion on the subject. it's possible some minor stuff might break, but i think it can be mostly a compatible change. where it can't be compatible, i'd vote that we make a breaking change because the new plan for how to do this is a lot better than the old plan.

2. #1255537 - rename StaticResource->PackageResouce and StaticResourceReference->PackageResourceReference

i'm +1 on both of these of course and can take care of them both sometime in the next week or so.

finally, i opened #1256084 - i'd really like someone else to write this page navigation code package if possible. it's a fun little project of its own and ought to be /really/ clean and simple and have nothing to do with listview or any other component.

    jon




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to