Excerpthiddentrue

Comparing Wicket & Tapestry

...

...

...

I haven't used Tapestry in a while and don't remember much... so somebody please continue the comparison...

Comparing Wicket and Tapestry

...

Although they are both component oriented frameworks, they have
completely different approaches. In wicket the focus is on java
code not on the template. Wicket templates are simple and limited
(purposefully) whereas tapestry allows for a lot more customization
from within the template. Wicket's approach makes sure all your
logic is kept in code. That is the wicket way.

– Igor Vaynberg

...

Some of the main differences:

• Wicket is not a managed framework. That means that
  you - the programmer - are in charge of component creation
  yourself. You do this with javacode opposed to doing it
  declarative.

Pro: gives you flexibility/ you wont be limited
by what the framework builders thought up/ you
don't have to learn how the framework manages
and how the declaring language (xml) works.

Con: harder to integrate with other frameworks
sometimes/ wicket internals sometimes difficult.

• (like Igor said) Wicket purposefuly does not support scripting
  like features in your markup.

Pro: everything stays very clean and it is easier to guess
how things should be done.

Con: harder for people that are used to a 'php/jsp way of
doing things' and you need programmers that at least
understand the basics of OO Java programming.

Pro: clarity and cleaneness. Con: some things are more
work with Wicket and you have to keep your java
component tree in sync with the markup nesting.

• With Wicket every component is truly stateful. Every
  property you define is part of it's state, and there
  is a flexible undo mechanism you can use to support
  any advanced backbutton support you might want.
  No need for a rewind mechanism. Furthermore, wicket
  component can be nested and can take part of any
  collaboration you want in the same fashion you could
  do in e.g. Swing.

Pro: flexibility and very easy to do complex things
if you know your Java.

Con: sometimes easy to end up with unoptimized spaghetti
like code if you take too many short cuts (much
like you could have with Swing).

• Creating custom components with Wicket is super easy.
  Just extend from an existing one (or from base class
  WebComponent or WebMarkupContainer), make it available
  in your classpath and your done. There's no extra
  configuration (libraries) and magical strings (ids)
  involved. For advanced component initialization, you
  can use IInitializer.
  • Eelco Hillenius

...

<div id="menu">
<p class="menu-item">Item 1</p>
<p class="menu-item"><a href="item2.html">Item 2</a></p>
<p class="menu-item"><a href="item3.html">Item 3</a></p>
<p class="menu-item"><a href="item4.html">Item 4</a></p>
</div>

...

All you need to do is create the localised page for each Page in your application. For instance:

...

...

Hello.java
Hello.html
Hello_fr.html
Hello_ja.html
...

...

The application will auto-detect the default language setting on the client machine and serve that locale by default. If the locale is unknown, it will default to that provided in the file with no locale specification (so in our example, "Hello.html").

You can switch locales by simply adding a link to your page, such as:

...

...

In Hello*.html

<a href="#" wicket:id="toJapaneseLink">Japanese.]</a>

See the "pub" example for a very simple, but concrete implementation.