Hi All,
Wicket uses mostly ResourceReferences to render and manage the URLs for
CSS and JavaScript files to be included in the output.
When we use libraries like JQuery UI, Bootstrap etc, it is often a
requirement to allow the user to provide his own customized resource
references. Typically, our code that integrates Wicket with these
libraries provides a "settings" object, which contains getters and
setters for resource references, as well as some other variables that
manipulate the libraries behavior.
eg:
https://github.com/sebfz1/wicket-jquery-ui/blob/master/wicket-jquery-ui-core/src/main/java/com/googlecode/wicket/jquery/core/settings/IJQueryLibrarySettings.java
I want to propose some behavior regarding these settings objects, which
will hopefully make our lives a little easier. Initially, I just want to
generate discussion. We can talk and decide what is the best plan (or if
any plan is needed).
At the moment, the general pattern I have observed is: Settings objects
are configured on the Application. renderHead() retrieves the settings
object from the Application, and uses the resource reference configured
that settings object to render the header items. Sometimes, if there is
no Application, or no settings object registered with the application,
then the default resource references packaged with the wicket
integration of the library are used.
The problem I have with this is that it only really allows for one set
of resources references/settings per application. (Yes, I know
wicket-bootstrap has theme providers etc, but I'm talking about your day
to day Wicket/JS library integration that uses the pattern above). If
you have page A and page B, which both use JQueryUI, for example, and
both require *different* customized JQueryUI resource references, or
each require different settings for the JQueryUI library, then it
becomes complicated.
What I have been doing recently is this: settings object are
Serializable. There are default settings if no settings object can be
found. Settings objects can be registered to Application using MetaData
pattern (saves us having to use a special type of Application), and,
importantly, settings objects can also be registered to Pages, again
using the MetaData pattern.
This way, you can have separate settings for each page, and have
multiple pages using wildly different customizations of the library.
Basically, renderHead() code looks something like this:
renderHead(Component component, IHeaderResponse response)
{
MyLibrarySettings settings = MyLibrary.getSettings(component);
// render head using MyLibrary settings.
}
and you have helper methods like:
public class MyLibrary
{
private static final MetaDataKey<MyLibrarySettings> key = ...;
public static void setApplicationSettings(Application app,
MyLibrarySettings settings)
{
app.setMetaData(key, settings);
}
public static void setPageSettings(Page page, MyLibrarySettings
settings)
{
page.serMetaData(key, settings);
}
public static void getSettings(Component component,
MyLibrarySettings settings)
{
MyLibrarySettings settings = component.getPage().getMetaData(key);
if (settings == null){
settings = Application.get().getMetaData(key);
}
if (settings == null){
settings = getDefaultMyLibrarySettings();
}
return settings;
}
}
What do you all think?
Thanks,
Jesse
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
