I like these points.
> 1. All code is Java, which enables end-to-end refactoring and gives
> you clean html.
And static typing gives you also good means to navigate your code. Use your
IDE to find the uses, overrides, etc. Make unsupported (due to API breaks)
methods final so that your clients break hard. Users of your components can
use code completion and javadoc hoovers. All the good Java stuff.
> 2. Composition enables reuse. When I took a panel and moved it from a
> tab on a page to a modalwindow on the page by changing a couple of
> lines of code it made a big impact.
Another thing that is good about composition is that it makes it easier to
divide work. You don't have to work from page to page, but rather can pick
an course to very fine components.
> 3. Components have session state. Hence the content of the session is
> determined by what components are on the page -- and further the
> session is cleaned out as components leave scope. (And if state is
> kept in url parameters then session is not used, in case anyone
> complains about session size. State must be somewhere, no?)
In the new version of Wicket In Action's chapter one, I state this:
"Wicket bridges the impedance mismatch between the stateless Hypertext
Transfer
Protocol (HTTP) and stateful Java programming." I added this after Dhanji
Prasanna asked me what I planned to say about that, which finally got that
light-bulb fired: 'that's indeed the core-core problem that Wicket tries to
solve'.
Unfortunately, the new chapter wasn't included in the last MEAP download,
but I'm sending it to Cemal directly. I hope I do a better job than before
explaining the key points of Wicket.
Another (potential) interesting point is that Wicket is secure by default.
Here is an excerpt of chapter 12 (authentication and authorization):
"With Wicket, if you don't code using bookmarkable pages, you use session
relative pages - Wicket's default way of coding web applications. Page
instances are kept on the server and you ask Wicket (through your browser)
for a certain page by providing the page number, version and the component
that is the target of the request. This works in the opposite way of the
REST architectural pattern, which states that servers should not keep state,
but clients provide servers with the relevant state when they issue
requests. As we saw in the first chapter, REST is great for scalability, but
lousy for the programming model. And now we get to another problem with
REST: the pattern is inherently unsafe, whereas Wicket's server state
pattern is safe by default.
For instance, if you implement the functionality of removing an object using
a link like this:
final MyObject myObject = …
new Link("remove") {
myDao.remove(myObject);
}
you never need to be worried about pimple faced fourteen year olds trying to
'hack' your web application. They would have to hijack the session, guess
the - session relative - page ids and version numbers, and the relevant
component paths. Very unlikely anyone ever will pull that off. And you can
even make your Wicket application more secure by encrypting requests with
for instance CryptedUrlWebRequestCodingStrategy. It simply doesn't get any
safer.
The REST variant of building your application would use bookmarkable pages
like this:
public DeleteMyObjectPage(PageParameters p) {
super(p);
Long id = p.getLong("id");
myDao.remove(MyObject.class, id);
}
The latter example, which is similar to how you would use "actions" or
"commands" with model 2 frameworks, is unsafe in two distinct ways. The
location of DeleteMyObjectPage can be guessed, thus exposing that
functionality to misuse. And even if users are authorized to access that
page and access itself is not a problem, they might only be authorized to
delete certain instances of MyObject. Without explicit protection, they
could guess ids or even write a script to delete whole parts of the
database. That means extra coding and potential security holes that can be
overlooked, whereas the 'session relative way' doesn't require you to do
anything extra in this respect."
Personally, I think this is a great feature. Though in all fairness, session
relative pages also makes testing harder.
Eelco
