THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Children Display | ||||||
|---|---|---|---|---|---|---|
|
Best Practices
Html Template Declaration
...
Otherwise, there's a risk the wicketservlet will handle the job to serve static resources, instead of the container.
For example,let's say you have /myapp/images/foo.gif and you map your wicket servlet to /* and dpn't have set ignorePaths.
Antipatterns
Anti-Pattern #1.
| Code Block |
|---|
public FooPanel(String id,IModel<User> userMdl) {
super(id,userMdl);
final User user = getModelObject();
IModel<List<User>> model = new LoadableDetachableModel<List<User>>() {
private static final long serialVersionUID = 1L;
@Override
protected List<User> load() {
// A Stale User entity is now serialized with each page view
// This can consume lots of session space if the user entity is large.
return getWebSession().getUserService().getUserFriends(user);
}
};
}
|
Here
...
is
...
the
...
correct
...
way
...
to
...
do
...
this
| Code Block |
|---|
//IModel needs to be a LoadableDetachableModel!
public FooPanel(String id,IModel<User> userMdl) {
super(id,userMdl);
final User user = getModelObject();
IModel<List<User>> model = new LoadableDetachableModel<List<User>>() {
private static final long serialVersionUID = 1L;
@Override
protected List<User> load() {
User uuser = FooPanel.this.getModelObject();
return getWebSession().getUserService().getUserFriends(uuser);
}
};
}
|
The
...
entity
...
is
...
fetched
...
each
...
page
...
view,
...
and
...
NOT
...
serialized
...
with
...
the
...
page.
...
The
...
only
...
thing
...
that
...
gets
...
serialized
...
is
...
the
...
fetching
...
model.
...
Anti-Pattern #2.
| Code Block |
|---|
public FooPanel(String id,IModel<User> userMdl) {
super(id.userMdl);
User user = getModelObject();
// Doh! user is not serialized with each page view, since the PropertyModel holds a reference!
add(new Label("name",new PropertyModel(user,"screenName")));
}
|
Here
...
is
...
the
...
correct
...
way
...
to
...
do
...
this:
| Code Block |
|---|
public FooPanel(String id,IModel<User> userMdl) {
super(id.userMdl);
add(new Label("name",new PropertyModel(userMdl,"screenName")));
}
|
The
...
PropertyModel
...
holds
...
a
...
reference
...
to
...
the
...
Model
...
which
...
fetches
...
the
...
User
...
on
...
each
...
page
...
view.
...
That
...
way
...
the
...
User
...
object
...
is
...
always
...
fresh
...
and
...
is
...
not
...
serialized
...
with
...
the
...
page.
...
Anti-Pattern #3.
| Code Block |
|---|
public FooPanel(String id,User user) {
// The stale User object will be in your session
// for the life span of the stateful page.
super(id.new Model(user));
}
|
Here
...
is
...
the
...
correct
...
way
...
to
...
do
...
this,
...
though
...
not
...
very
...
elegant.
| Code Block |
|---|
public FooPanel(String id,User user) {
super(id);
final int id = user.getId();
setModel(new LoadableDetachableModel<List<User>>() {
@Override
protected List<User> load() {
return getUserDao().findById(id);
}
|
antipattern 1-3 from blog letsgetdugg, thanks
Anti-pattern #4. - Anonymous Inner classes
Don't do this:
| Code Block |
|---|
class MyPage extends WebPage {
private MyVeryLargeObject subject;
// ....
public MyPage() {
// get my very large object from database
subject = MyVeryLargeObjectDao.get();
// ...
form.add(new TextField("name", new PropertyModel(MyPage.this, "some.very.large.navigational.structure.name"));
}
}
|
The 'subject' instance of the MyVeryLargeObjectDao class will be serialized into the session with each page version. This can get out of hand, because with some business object models, the attached object can become very large. For this we introduced DetachableModels, which will retrieve the data from the database when needed, and will clean up when the data is not needed (at the end of the request for instance).
The other thing to avoid is be careful about are anonymous or nested instances subclasses of IModel. Usually you shouldn't share an instance of a model between two page instances. If But if you create an anonymous or nested instance of IModel, then you automatically get a 'this' reference to the class that surrounds it. This will usually be the page, but can also be the form or a listview. Anyway, because the reference is /final/, you will copy that reference to the old page, with the model to the new page, thus duplicating the component tree (it gets versioned etc.). This will eventually lead to OutOfMemoryError.
...
PBEWithMD5AndDES not found
Wiki Markup
Not entirely clear what causes this.
...
- download http://www.bouncycastle.org/download/bcprov-jdk15-133.jar
- put it in jre\lib\ext
- in java.security (jre\lib\security), add this security provider:
Code Block security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
Wiki Markup
I've only seen this under the SysDeo Tomcat plug-in for Eclipse, when the boot classpath wasn't configured properly to include jce.jar, etc. – Al Maw
...
http://www.devproof.org/wicket_best_practice - Devproof best practices
http://blog.worldturner.com/worldturner/entry/wicket_best_practices_components_vs blog worldtuner
http://www.small-improvements.com/10-things-about-apache-wicket-i-love/wicket:pageMapName/wicket-0 - 10 things to know..
http://stronglytypedblog.blogspot.se/2009/04/wicket-patterns-and-pitfalls-5.html Wicket pitfalls 5 articles
http://wicketinaction.com/ in action - lots of good stuff if searching here