The conclusion is that I we can't change our package resource
implementation at this time. So for Wicket 1.2. you still have to
pre-register you the package resources you want to expose. However,
you can do it with a pattern now:
PackageResource.bind(application, PackageResourceTest.class,
Pattern.compile(".*\\.js"));
or using the shorthand for js files (also exists for css files):
PackageResource.bind(application, ComponentInitializer.class,
PackageResource.EXTENSION_JS);
This new bind function will not recurse into subdirectories.
So to be complete, if you want to expose all you js files in a package
as (shared) package resources, this is what you need to do (example
from extensions project):
Create a component initializer:
public class AbstractYuiPanel extends Panel
{
(1)
public final static class ComponentInitializer implements IInitializer
{
public void init(Application application)
{
PackageResource.bind(application,
ComponentInitializer.class,
PackageResource.EXTENSION_JS);
}
}
...
Add that resource to you jar's initializer:
(2)
public class Initializer implements IInitializer
{
public void init(Application application)
{
new AbstractYuiPanel.ComponentInitializer().init(application);
...
}
}
If you are creating a new jar - i.e. you don't have a component
initializer - register the initializer by putting a wicket.properties
file in the root of your classpath, and have a line in it like:
(3)
initializer=wicket.extensions.Initializer
Which should point to (2).
>From now on all js files will be accesible from your package, and
refering from one js file to another can be done relatively, without
the need to do anything extra in Wicket. You can do the same thing for
css files, images and anything you like.
A few notes:
* Having a seperate initializer might seem like overkill, but it is
needed to make the package resources available regardless of any
sessions and guarantee correct clustering behavior.
* It is not advisable to use package resources as a database. Besides
the fact that this was never our intention with package resources,
some servlet containers (like Tomcat) seem to be very persistent in
holding references to them, putting an extra strain on your server
side memory. I'm not sure what the issues are exactly from the top of
my head, but you can find discussions about this in the mailing
archives.
* The approach which I outlined above is a defensive approach. To the
upside of this, you'll never expose anything in your package without
intend. The downside is that it is more work for component authors to
work with package resources than it would be with a more optimistic
approach. An optimistic approach has issues with where to load the
resources from - with which classloader -, and we (core members)
currently do not all agree that the optimistic approach would be best.
So, like I said earlier, this is to be evaluated for future releases,
and any alternative approach has to be one that works for OSGi too.
Hope this helps,
Eelco
On 3/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> I am currently investigating if we can do without the explicit
> registration. We can't totally do without, as we need at least
> classloader to load any resources like that, but the intend now is to
> make it at least easier. More about this later this week.
>
> Eelco
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
