You're discussing the fact that it is up to the developer to manually
initialize these resources in his Application while the component
developer (might be a separate guy) has no way to automatically export
them into his application. Correct?
Well, let me put it this way: before you couldn't even get this working
*at all*. Now you can at least declare these images in the Application
manually. Sure it isn't perfect but at least now there is a workaround.
If you want that second half (automatic exporting of application-scoped
resources) then that's a whole different discussion. It's simple an ease
of use issue as far as I'm concerned (although it would be nice to fix it).
Jon suggested using an XML configuration file. I suggested adding a
method to components (I mistakenly said Page but I meant for all
components) that allows them to return a list of all resources they wish
to export. etc... but can we at least begin by commiting the first part
of the fix into CVS? The current CVS head branch does not work at all
for Application-scoped static resources.
Gili
Johan Compagner wrote:
it is not fixed.
Please READ my mail.
You can't just instantiate every resource you are using in youre app
Because you don't KNOW them all. If you are using datepicker. Are you
aware that it uses a lot of StaticResources?? Really a lot??
Those should all be made in youre application, are you doing that?
johan
Gili wrote:
gawd! Sorry but I'm -100 on any XML configuration file. Why do we
need this anyway? I fixed StaticResourceReference so you can hit
images without constructing a Page... it's fixed... why refactor
everything?
Gili
Jonathan Locke wrote:
Johan Compagner wrote:
WicketApplication gets something like: registerComponent()
that must be called in the init of the Application object for every
component it uses (that request this in the doc or something)
So that that component can register/make its PackageResources
available.
But i don't like this very much
i think some variant of this is probably more the right approach. i
really want resources to stay
scoped by the application. this is better OO and will avoid
conflicts and other issues. seriously.
i think we are on the right track. we should not undo something
that's well-structured and working
to fix this problem. yes, we do have a problem with resource
registration, but i think i have a
fairly decent idea how to fix this...
DESIGN GOALS:
1. enable auto-registration of components and related global
resources
2. put the burden on component designers not users
3. make it easy for component designers to get their resources
registered with the application
4. solution should not interfere with the current simple way of
developing and using components and resources
SOLUTION:
1. user puts component jars and classfiles on classpath and is
blissfully ignorant of what's going on
2. Application constructor enumerates through jars and classes via
ClassLoader.getResources()
looking for xml metadata, each package containing a
Components.xml file
a. each xml file is processed to register resources for any
components in the jar or classpath folder
b. the minimum format for this xml file would be something like:
<wicket-components>
<wicket-component class="wicket.whatever.MyComponent"
load="true/false">
<resources>
<package-resource path="images/foo.gif"
locale="en_CA" style="sporty"/>
...
</resources>
</wicket-component>
</wicket-components>
resources not registered using the <resource> declarations
for PackageResources would have to
be registered by setting load="true" and using a static
initializer block to do the work.
we can talk more about the format and where the info should
go, but the basic idea seems solid...
2>
Don't bind PackageResources or StaticResources in the SharedResources.
They are already holding references to the StaticImages inside them
self (there static map)
So shared resources should somehow look there. But we need to store
also the scope/locale and style then.
The you can use them statically and the serializable problems are
gone and the PackageResources are there
BEFORE the page so the page doesn't also have to be instantiated
again. (only the class has to be loaded)
johan
Jonathan Locke wrote:
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
-------------------------------------------------------
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
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
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
