Wicket Web Spiders

Wicket FAQ

pons — Fri, 30 Apr 2010 04:52:50 +0000

you can find frequently asked questions here

wicketfaq.wordpress.com

Template for Building Authenticated WebApplication

pons — Fri, 08 Jan 2010 02:46:36 +0000

Here is the Role based Authenticated template for the wicket developer those who are in a hurry

the structure of the Netbeans application is as follows

This article illustrates Wicket’s approach to testability, authentication and authorization, form handling, page nesting, file uploads with progress feedback, and the classic back-button problem. Throughout the development steps, the example highlights noteworthy pieces of code and describes what’s going on behind the scenes.
Step 1: Enforcing Page Authorization
Wicket’s unique WicketTester class isolates applications in simulated servlet containers, and provides high-level methods for interacting with them. This enables test-driven design with functional tests such as the following, which specifies that anonymous users should be sent to the LoginPage:

@Test public void shouldAuthChallenge() { wicketTester.startPage(FileInfoPage.class); wicketTester.assertRenderedPage(LoginPage.class); }
To establish authorization and authentication, the application class must extend AuthenticatedWebApplication, specify a login page, and use a WebSession derived from AuthenticatedWebSession as follows:


public class ExampleWicketApplication extends AuthenticatedWebApplication
{
  @Override
  protected Classextends WebPage> getSignInPageClass()
  {
    return LoginPage.class;
  }

  @Override
  protected Classextends AuthenticatedWebSession> getWebSessionClass()
  {
    return ExampleWebSession.class;
  }

...

Sessions have many responsibilities in Wicket; they aren’t simply generic containers for persistent variables as in other frameworks. In this case, ExampleWebSession implements the means of

authentication (more on the role of sessions later). The following code adds authorization protection to the FileInfoPage:


@AuthorizeInstantiation("USER")
public class FileInfoPage extends BasePage
{

...

The shouldAuthChallenge test now passes, and you’re ready to implement authentication.

Step 2: Enabling Authentication

Now that users are being sent to the LoginPage, you can test to assure that they are able to log in as a guest and get forwarded to the FileInfoPage:

  @Test
  public void shouldAllowGuestAuth()
  {
    wicketTester.startPage(FileInfoPage.class);
    wicketTester.assertRenderedPage(LoginPage.class);

    FormTester formTester
      = wicketTester.newFormTester("signInPanel:signInForm");
    formTester.setValue("username", "guest");
    formTester.setValue("password", "guest");
    formTester.submit();

    wicketTester.assertRenderedPage(FileInfoPage.class);
  }

This test takes a bit of research. You need to look into the markup of the stock SignInPanel component to determine the ID of the form (“signInForm”) and its input IDs (“username” and “password”). Luckily this is simple to do using your IDE’s package explorer. You may have noticed that having markup in disparate locations like this could break separation of concerns. Wicket brings together LoginPage.java and LoginPage.html when rendering the LoginPage.

One simple link exists between the two: the wicket:id HTML attribute, which anchors components at specific locations on the page:


public class LoginPage extends BasePage
{
  public LoginPage()
  {
    add(new SignInPanel("signInPanel"));
  }
}












The string signInPanel, which places the SignInPanel inside a div in the markup, is one of the only points where you lose type
safety in Wicket applications. Luckily, WicketTester helps you catch typos in an automated fashion, and the framework provides detailed
debugging output when components in the code don't match up to those specified in the markup.

Next, you implement authentication and authorization inside ExampleWebSession:

  @Override
  public boolean authenticate(String userName, String password)
  {
    boolean success = userName.equals("guest") && password.equals("guest");

    if ( success )
      this.userName = userName;

    return success;
  }

  @Override
  public Roles getRoles()
  {
    Roles roles = new Roles();

    if ( isSignedIn() )
      roles.add("USER");

    return roles;
  }

This example permits guests to authenticate, and it authorizes them to instantiate the FileInfo page via the USER role. Wicket automatically forwards guests to the
original destination, and the "shouldAllowGuestAuth" test now passes.

Step 3: Markup Nesting Through Inheritance
Going back to the markup for LoginPage for a second, did you notice the "wicket:extend" tags? This is Wicket's object-oriented approach to markup nesting. In this case, the BasePage
contains the following markup, which acts as a header and footer for all pages that extend it:


FileDropoff





Wicket Authenticated web Application example




Step 4: Form Handling, Component Style
Now that users can reach the FileInfoPage, you specify that they should be able to enter some info and advance to the upload page:
  @Test
  public void shouldAcceptInfoAndAdvance()
  {
    shouldAllowGuestAuth();
    FormTester formTester = wicketTester.newFormTester("metaDataForm");
    formTester.setValue("title", "Alpine Lakes Trail");
    formTester.setValue("tags", "hike, forest, alpine lakes");
    formTester.submit();

    wicketTester.assertRenderedPage(FileUploadPage.class);
  }

Now you will implement a component of your own: a simple form. Creating reusable components in Wicket is as simple as writing a small Java class that derives from the framework:
public class FileInfoPage extends BasePage
{
  private class FileInfoForm extends Form
  {

...

You will need a constructor that accepts a markup ID like SignInPanel does:
    public FileInfoForm(String id)
    {
      super(id);

      setModel(new CompoundPropertyModel(new UserContributedFile()));

      add(new RequiredTextField("title")
        .add(StringValidator.maximumLength(32)));
      add(new TextField("tags")
        .add(StringValidator.maximumLength(32)));
    }

Components have backing model objects that generally wrap instances of entity classes (note the call to setModel above). This example has one such class, UserContributedFile,the
properties of which the form will allow users to edit. Different types of models facilitate different behaviors for things such as serialization and data access—in this case
CompoundPropertyModel is the simplest choice. wicket expresses field validation rules as objects. You can see the composite pattern in use above, as you added text fields to your
form and then validators to your text fields in chain invocation fashion. You can also imagine how Wicket will use the visitor pattern later to spider the fields and apply the
validators on submission.

Wicket's Event-Driven Model and PageMap
In keeping with the use case, it's time to move on to FileUploadPage. Override the default onSubmit method in Form:
    @Override
    protected void onSubmit()
    {
      super.onSubmit();

      FileUploadPage fileUploadPage = new FileUploadPage(getModel());
      setResponsePage(fileUploadPage);
    }

Wicket’s event-driven, unmanaged nature is clear here; whatever page you add a FileInfoForm to, submitting that instance of FileInfoForm executes the event handler and sends the user to a newly constructed FileUploadPage. The model object is already populated with validated values at this point, and you pass it to the next page’s constructor. This is a departure from other frameworks, which often use the session to marshal objects from one page to the next. Wicket maintains a server-side cache of the object graphs that represent each page rendered to the user. This makes your application a true state machine, and effectively solves the classic back button problem. For example, after advancing to the FileUploadPage, the user can hit the back button and Wicket will deserialize and render a copy of the object that represents the FileInfoPage the user was just on. The FileInfoForm’s model is part of the object graph of the page, and so Wicket deserializes it and binds it to the form with all the values last submitted by the user intact. This is a much more effective way to manage moving back and forth in multipage workflows than juggling session variables.

File Upload with AJAX Progress Feedback

The “shouldAcceptInfoAndAdvance” test now passes, and users can get as far as the FileUploadPage. The last step is for them to be able to upload their files, which you specify with the following test:

  @Test
  public void shouldAcceptFileUpload()
  {
    shouldAcceptMetaAndAdvance();

    FormTester formTester = wicketTester.newFormTester("fileUploadForm");
    formTester.setFile("fileInput", TEST_UPLOAD_FILE, "image/jpeg");
    formTester.submit();

    String uploadedFilePath = TEST_UPLOAD_FOLDER.getAbsolutePath()
      .concat( File.separator )
      .concat("guest.jpg");

    java.io.File uploadedFile = new java.io.File(uploadedFilePath);

    Assert.assertTrue
      ("File not deposited in upload folder or incorrectly named.",
          uploadedFile.exists());

    uploadedFile.delete();
  }
}

Now you implement your second Form component: FileUploadForm. You can read the onSubmit event handler later, but for now take a closer look at the constructor and Wicket’s AJAX support:


public class FileUploadPage extends BasePage
{
  private class FileUploadForm extends Form
  {
    private FileUploadField fileUploadField;

    public FileUploadForm(String id)
    {
      super(id);

      setOutputMarkupId(true);

      setMultiPart(true);
      setMaxSize(Bytes.megabytes(3));

      add(fileUploadField = new FileUploadField("fileInput"));
      add(new UploadProgressBar("progress", this));
    }

Source code for all the above structured figure

web.xml





wicketexample



wicketexample

org.apache.wicket.protocol.http.WicketFilter



applicationClassName

com.pons.ExampleWicketApplication







wicketexample

/*





BasePage.html











Insert title here





FileDropoff





wicket Authenticated web application






BasePage.java

package com.pons;

import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.model.IModel;

public class BasePage extends WebPage
{
 public BasePage()
 {
 super();
 }

 public BasePage(IModel model)
 {
 super(model);
 }
}

ExampleWebSession.java
package com.pons;

import org.apache.wicket.Request;
import org.apache.wicket.authentication.AuthenticatedWebApplication;
import org.apache.wicket.authentication.AuthenticatedWebSession;
import org.apache.wicket.authorization.strategies.role.Roles;

public class ExampleWebSession extends AuthenticatedWebSession
{
 private String userName;

 public ExampleWebSession(AuthenticatedWebApplication application, Request request)
 {
 super(application, request);
 }

 @Override
 public boolean authenticate(String userName, String password)
 {
 boolean success = userName.equals("guest") && password.equals("guest");

 if ( success )
 this.userName = userName;

 return success;
 }

 @Override
 public Roles getRoles()
 {
 Roles roles = new Roles();

 if ( isSignedIn() )
 roles.add("USER");

 return roles;
 }

 public String getUserName()
 {
 return userName;
 }
}

ExampleWicketApplication.java

package com.pons;

import java.io.File;

import javax.servlet.http.HttpServletRequest;

import org.apache.wicket.authentication.AuthenticatedWebApplication;
import org.apache.wicket.authentication.AuthenticatedWebSession;
import org.apache.wicket.extensions.ajax.markup.html.form.upload.UploadWebRequest;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.protocol.http.WebRequest;

/**
 * Application object for your web application. If you want to run this
 * application without deploying, run the Start class.
 */
public class ExampleWicketApplication extends AuthenticatedWebApplication
{    
 private File uploadFolder;

 /**
 * Constructor
 */
 public ExampleWicketApplication()
 {
 }

 @Override
 protected Class getSignInPageClass()
 {
 return LoginPage.class;
 }

 @Override
 protected Class getWebSessionClass()
 {
 return ExampleWebSession.class;
 }

 public Class getHomePage()
 {
 return FileInfoPage.class;
 }

 /**
 * @return the uploadFolder
 */
 public File getUploadFolder()
 {
 return uploadFolder == null ? new File(".") : uploadFolder;
 }

 @Override
 protected WebRequest newWebRequest(HttpServletRequest servletRequest)
 {
 return new UploadWebRequest(servletRequest);
 }

 /**
 * @param uploadFolder the uploadFolder to set
 */
 public void setUploadFolder(File uploadFolder)
 {
 this.uploadFolder = uploadFolder;
 }
}

FileInfoPage.html











Enter File Info













Title:







Tags:

















FileInfoPage.java
package com.pons;

import org.apache.wicket.authorization.strategies.role.annotations.AuthorizeInstantiation;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.RequiredTextField;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.CompoundPropertyModel;
import org.apache.wicket.validation.validator.StringValidator;

@AuthorizeInstantiation("USER")
public class FileInfoPage extends BasePage
{
 public FileInfoPage()
 {
 super();

 add(new FileInfoForm("metaDataForm"));
 }

 private class FileInfoForm extends Form
 {
 public FileInfoForm(String id)
 {
 super(id);

 setModel(new CompoundPropertyModel(new UserContributedFile()));

 add(new RequiredTextField("title")
 .add(StringValidator.maximumLength(32)));
 add(new TextField("tags")
 .add(StringValidator.maximumLength(32)));
 }

 @Override
 protected void onSubmit()
 {
 super.onSubmit();

 FileUploadPage fileUploadPage = new FileUploadPage(getModel());
 setResponsePage(fileUploadPage);
 }
 }
}

FileUploadPage.html











Enter File Info



























FileUploadPage.java

package com.pons;

import java.io.File;
import java.io.IOException;

import org.apache.wicket.authentication.AuthenticatedWebApplication;
import org.apache.wicket.authentication.AuthenticatedWebSession;
import org.apache.wicket.extensions.ajax.markup.html.form.upload.UploadProgressBar;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.upload.FileUpload;
import org.apache.wicket.markup.html.form.upload.FileUploadField;
import org.apache.wicket.model.IModel;
import org.apache.wicket.util.lang.Bytes;

public class FileUploadPage extends BasePage
{
 // user-File_Title-tag1+tag2+tag_3.ext
 private static final String FILENAME_FORMAT = "%s-%s-%s.%s";

 public FileUploadPage(IModel userContributedFileModel)
 {
 super(userContributedFileModel);
 add(new FileUploadForm("fileUploadForm"));
 }

 private class FileUploadForm extends Form
 {
 private FileUploadField fileUploadField;

 public FileUploadForm(String id)
 {
 super(id);

 setOutputMarkupId(true);

 setMultiPart(true);
 setMaxSize(Bytes.gigabytes(1));

 add(fileUploadField = new FileUploadField("fileInput"));
 add(new UploadProgressBar("progress", this));
 }

 @Override
 protected void onSubmit()
 {
 super.onSubmit();

 final FileUpload upload = fileUploadField.getFileUpload();

 if ( upload == null )
 return;

 File tempFile;
 try {
 tempFile = upload.writeToTempFile();
 }
 catch ( IOException e ) {
 throw new RuntimeException("Unable to write file upload.", e);
 }

 File uploadFolder
 = ((ExampleWicketApplication) getApplication()).getUploadFolder();

 String userName
 = ((ExampleWebSession) getSession()).getUserName();

 UserContributedFile userContributedFile
 = (UserContributedFile) getPage().getModelObject();

 String remoteFileName = upload.getClientFileName();

 String destinationFileName = String.format(FILENAME_FORMAT, userName,
 userContributedFile.getTitle(),
 userContributedFile.getTagsUsingDelimiter('+'),
 remoteFileName.substring(remoteFileName.lastIndexOf('.') + 1));

 tempFile.renameTo(new File(uploadFolder.getAbsolutePath()
 .concat( File.separator )
 .concat(destinationFileName)));
 }
 }
}

LoginPage.html











 Log In















LoginPage.java

package com.pons;

import org.apache.wicket.authentication.panel.SignInPanel;
import org.apache.wicket.markup.html.WebPage;

public class LoginPage extends BasePage
{
 public LoginPage()
 {
 add(new SignInPanel("signInPanel"));
 }
}

LogoutPage.java

package com.pons;

public class LogoutPage
{

}

UserContributedFile.java

package com.pons;

import java.io.File;
import java.io.Serializable;
import java.util.StringTokenizer;

import org.apache.commons.lang.StringUtils;

public class UserContributedFile
 implements Serializable
{
 private String title;
 private String[] tags;
 private File file;

 /**
 * @return the title
 */
 public String getTitle()
 {
 return title;
 }
 /**
 * @param title the title to set
 */
 public void setTitle(String title)
 {
 this.title = title;
 }

 /**
 * @return the tags
 */
 public String getTags()
 {
 return StringUtils.join(tags, ", ");
 }

 /**
 * @return the tags
 */
 public String getTagsUsingDelimiter(char delimiter)
 {
 return StringUtils.join(tags, delimiter);
 }

 /**
 * Set tags using a comma and whitespace separated list.
 *
 * @param tags
 */
 public void setTags(String tags)
 {
 this.tags = StringUtils.splitByWholeSeparator(tags, ", ");
 }

 /**
 * @return the file
 */
 public File getFile()
 {
 return file;
 }
 /**
 * @param file the file to set
 */
 public void setFile(File file)
 {
 this.file = file;
 }
}
Inside Test Package

Start.java (this ensures the starting of embedded Jetty server)

package com.pons;

import org.mortbay.jetty.Connector;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.bio.SocketConnector;
import org.mortbay.jetty.webapp.WebAppContext;

public class Start {

 public static void main(String[] args) throws Exception {
 Server server = new Server();
 SocketConnector connector = new SocketConnector();
 connector.setPort(8085);
 server.setConnectors(new Connector[] { connector });

 WebAppContext bb = new WebAppContext();
 bb.setServer(server);
 bb.setContextPath("/wicketexample");
 bb.setWar("src/main/webapp");

 server.addHandler(bb);

 try {
 System.out.println(">>> STARTING , PRESS ANY KEY TO STOP");
 server.start();
 while (System.in.available() == 0) {
 Thread.sleep(5000);
 }
 server.stop();
 server.join();
 } catch (Exception e) {
 e.printStackTrace();
 System.exit(100);
 }
 }
}

WicketApplicationTest.java
package com.pons;

import com.pons.LoginPage;
import com.pons.FileInfoPage;
import com.pons.FileUploadPage;
import com.pons.ExampleWicketApplication;
import junit.framework.Assert;

import org.apache.wicket.util.file.File;
import org.apache.wicket.util.tester.FormTester;
import org.apache.wicket.util.tester.WicketTester;
import org.junit.Before;
import org.junit.Test;

public class WicketApplicationTest
{
 private ExampleWicketApplication testApplicaton;
 private WicketTester wicketTester;

 private static File TEST_UPLOAD_FILE = new File("test-upload-image.jpg");
 private static java.io.File TEST_UPLOAD_FOLDER
 = new java.io.File("test-upload-folder");

 @Before
 public void setUpTestApplication()
 {
 if ( ! TEST_UPLOAD_FOLDER.exists() )
 TEST_UPLOAD_FOLDER.mkdir();

 testApplicaton = new ExampleWicketApplication();
 testApplicaton.setUploadFolder(TEST_UPLOAD_FOLDER);

 wicketTester = new WicketTester(testApplicaton);
 }

 @Test
 public void shouldAuthChallenge()
 {
 wicketTester.startPage(FileInfoPage.class);
 wicketTester.assertRenderedPage(LoginPage.class);
 }

 @Test
 public void shouldAllowGuestAuth()
 {
 wicketTester.startPage(FileInfoPage.class);
 wicketTester.assertRenderedPage(LoginPage.class);

 FormTester formTester = wicketTester.newFormTester("signInPanel:signInForm");
 formTester.setValue("username", "guest");
 formTester.setValue("password", "guest");
 formTester.submit();

 wicketTester.assertRenderedPage(FileInfoPage.class);
 }

 @Test
 public void shouldAcceptInfoAndAdvance()
 {
 shouldAllowGuestAuth();

 FormTester formTester = wicketTester.newFormTester("metaDataForm");
 formTester.setValue("title", "Testing");
 formTester.setValue("tags", "wood, forest,lakes");
 formTester.submit();

 wicketTester.assertRenderedPage(FileUploadPage.class);
 }

 @Test
 public void shouldAcceptFileUpload()
 {
 shouldAcceptInfoAndAdvance();

 FormTester formTester = wicketTester.newFormTester("fileUploadForm");
 formTester.setFile("fileInput", TEST_UPLOAD_FILE, "image/jpeg");
 formTester.submit();

 // for simplicity we store the previously collected meta information in
 // the file name.
 String uploadedFilePath = TEST_UPLOAD_FOLDER.getAbsolutePath()
 .concat( File.separator )
 .concat("lakes.jpg");

 java.io.File uploadedFile = new java.io.File(uploadedFilePath);

 Assert.assertTrue
 ("File not deposited in upload folder or incorrectly named.",
 uploadedFile.exists());

 uploadedFile.delete();
 }
}

Maven based pom.xml file




 4.0.0
 com.pons
 wicketexample
 war
 1.0-SNAPSHOT
 Example Wicket Application

 

 
 
 The Apache Software License, Version 2.0
 http://www.apache.org/licenses/LICENSE-2.0.txt
 repo
 
 

 
 

 
 org.apache.wicket
 wicket
 ${wicket.version}
 
 
 org.apache.wicket
 wicket-auth-roles
 ${wicket.version}
 
 
 org.apache.wicket
 wicket-extensions
 ${wicket.version}
 

 

 
 org.slf4j
 slf4j-log4j12
 1.0.1
 
 
 log4j
 log4j
 1.2.14
 

 

 
 org.mortbay.jetty
 jetty
 ${jetty.version}
 provided
 
 
 org.mortbay.jetty
 jetty-util
 ${jetty.version}
 provided
 
 
 org.mortbay.jetty
 jetty-management
 ${jetty.version}
 provided
 

 
 junit
 junit
 4.3.1
 test
 
 
 commons-lang
 commons-lang
 2.3
 
 

 
 
 
 src/main/resources
 
 
 src/main/java
 
 **
 
 
 **/*.java
 
 
 
 
 
 src/test/java
 
 **
 
 
 **/*.java
 
 
 
 
 
 org.apache.maven.plugins
 maven-compiler-plugin
 2.0
 
 1.5
 1.5
 
 
 
 org.mortbay.jetty
 maven-jetty-plugin
 
 
 

 
 1.3.3
 Tomcat60
 6.1.4

Why Wicket ?

pons — Wed, 06 Jan 2010 03:46:25 +0000

building………

Seam / JSF vs Wicket

pons — Wed, 30 Dec 2009 03:05:20 +0000

A while after Seam support for Apache Wicket was announced, I downloaded Seam and took a look at the Wicket example. Then an idea struck – how about doing a performance comparison – I mean, here was the very same application implemented in JSF and Wicket – right? So I decided to write a JMeter script for both the JSF and Wicket versions of the Seam “hotel booking” example and compare results. I started right away but very soon got tired of waiting for app-server re-starts on my trusty laptop (Jetty has really spoiled me) – and it kind of bothered me that the Seam examples were not in Maven 2 layout. Anyway, at some point I decided to re-write an “EJB-free” version of the Seam booking example using just Wicket and JPA. And use Maven and Jetty. And… one thing led to another – and what I ended up doing is this:

* Adapted the Seam JPA example (the one that does not use EJB) as the baseline application. Converted it into a Maven 2 WAR project which can run on Jetty.
* Implemented what I hope is the exact equivalent of the above using only Wicket and JPA, also Maven-ized and Jetty-fied. Decided to also experiment with some of the ideas in this blog post.
* Wrote a JMeter script for both applications taking care to exercise identical functionality.
* Used an Ant script to run the JMeter scripts in batch mode (passing number of concurrent users as a parameter) and start / stop Jetty in sync.
* Automated the entire cycle of running the load test for 1, 5, 10, 15 and 20 concurrent users including some code to parse the JMeter logs and generate a CSV file of tabular results.
* Also included an Ant target that takes a JVM heap dump at the end of the load test – just before the users are logged out and the HTTP sessions killed.

I was able to re-use the official Seam Wicket example to some extent, mainly the HTML files – but the Java side is almost completely re-written. The Seam booking example covers quite a bit of ground from the framework comparison point of view – for example:

* Security – some pages are secured and redirect to a login page
* Templating – some pages inherit from a common layout with a header / footer defined
* Ajax –
o hotel search results refresh as you type and a “busy” image is shown during the Ajax request
o form field validations occur as soon as the field loses focus
* Session scope – some state is stored and retrieved in the session
* Page navigation / state –
o user navigation state transparently managed by the framework
o user should be able to work in multiple concurrent conversations (browser tabs)
o the browser back button should work as expected
* JPA – getting access to the entity manager and transaction management
* Forms – binding, validation and displaying error / info feedback to the user
* Hibernate Validator – annotations on the JPA entity classes are re-used for form-validation

Both sides use the exact same entities, persistence.xml and initial HSQLDB import. I’m using the latest Seam 2.1.1-GA and Wicket 1.3.5. Disclaimer: my Wicket code may not be ideal, and I’ve also experimented with a custom RequestCycle for JPA and tried to use inherited models as far as possible. Instructions on how you can download the source and run the scripts on your local machine are at the end of this blog post.

I may do some follow up blog posts on how the code compares between the Seam / JSF and Wicket implementations, and also share some tips on writing JMeter scripts and automation using Jetty, Ant etc. I’m also expecting to have to make corrections and changes to the code based on feedback. For now, I’ll summarize my observations on performance and memory usage.

for more quench to go comparing performance clickhere

Comparing Wicket and Tapestry

pons — Wed, 30 Dec 2009 01:04:45 +0000

Overview

Both Wicket and Tapestry are component-based web application framework written in Java. Although the design approaches are very similar, some of the implementation details are quite different.

Moving to Wicket from Tapestry is double-edged: on the one hand, Tapestry users are already familiar with the component-driven approach, so should have no problem understanding Wicket concepts. On the other hand, however, the actual coding can be very different.

This article is aimed at Tapestry users moving over to Wicket. The goal is to give such users a running start by showing some of the key implementation details in Wicket that differ from Tapestry.

The Wicket Way

This is a quote taken from the mailing list:

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

And:

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

Coding Components

The main differences with Wicket when coding components are:

* there is no XML page file
* you cannot pass in parameters via HTML

Example: create a menu component

In this example, we will explore how to create a menu component for a website. The goal is to output HTML code such as the following:

Item 1 does not contain a link since it is the “active” page. The same would occur for any one of the other links when the page corresponding to that link is “active”.

Note that in most cases, you would not even need to think about this since Wicket’s component takes care of this for you. However, we will continue to use this as our example.

Internationalisation (i18n) is easy in Wicket, since it is supported out of the box.

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.java:

add(new Link(“indian”)
{
public void onClick()
Unknown macro: { getSession().setLocale( Locale.INDIAN ); }

});

In Hello*.html

Indian

Tapestry and Wicket are referred as modern component-based Web frameworks. Unlike the Model 2 architecture frameworks Struts or Spring MVC, Tapestry and Wicket offer a fresh approach to the process of Web development by emphasizing a methodology for thinking about Web applications, their behavior, and component interaction in the same way you think about stand-alone GUI-based applications.A typical component-based application represents a set of pages that consist of a set of components. The components, in turn, may be assembled from smaller components, etc. User interaction here is a specific component event. This is the main difference from MVC-based applications, where the entry point for interactions is a servlet or an action with general attributes (such as URLs, its parameters, forms, etc.).Developers who use component-based frameworks focus on components and their interaction by implementing event-driven models. Servlets, HTTP sessions, and other entities from the servlet API are moved one level lower and are never used directly. However, the developer is responsible for the server-side state through the way a component or its properties are declared, which can be session-persistent.

Both Tapestry and Wicket use their own template systems that allow creating HTML templates fully compliant with HTML standards. This gives us a clear separation of concerns: Web designers work on the GUI without a concern about what platform the application is written on; likewise, application developers implement the components not concerned with the final design of pages using stub elements for debugging and testing. Both Tapestry and Wicket support such separation.

While going on its way with Tapestry, it is heavily based on the HiveMind microkernel, which is a serious representation of Inversion-of-Control containers. All Tapestry services are registered using HiveMind.

A typical Tapestry component is assembled from a component specification that is an XML descriptor, from component logic that is a portion of the Java™ programming language and from UI layout that is an HTML template.On the other hand the wicket works is simple component basedAt the heart of the Wicket architecture is the Component class, which all components and markup containers extend. A component is responsible for dealing with its model — an implementation of the IModel interface. The model represents any kind of data relevant to the component instance and defines its behavior. One of the noticeable IModel implementations is the LoadableDetachableModel that allows passing transient data, loading it before rendering the component, and detaching (destroying) it when it is not needed anymore, thus reducing the size of the Wicket session.

Wicket pages are components also, and their states are stored in the Wicket session if they are stateful. Pages can be version-enabled, so every time the state of a page is changed (page is simply viewed, its components state is changed, etc.), it is stored with an incremented version number.

Comparing wicket with struts

pons — Wed, 30 Dec 2009 01:03:25 +0000

Overview

Wicket is an advanced component based web application framework. Its primary benefits are:

* Clean separation of concerns between HTML and Java
* Object-oriented component model
* Automated state management
* High productivity
* Low learning curve
* Abstraction away from Servlet API and HTTP protocol details
* No XML configuration files
* Easy to build reusable components

Struts is a Model2 MVC web application framework. It is based around action classes that handle HTTP requests. Configuration is by XML files. Struts is usually used in conjunction with another technology (usually JSP and custom tag libraries).

The remainder of this article addresses the main differences between the two frameworks and explains why Wicket is so much better than Struts (in our opinion).

General Philosophy

The philosophy adopted by Struts is based around intercepting each HTTP request to a web application and directing it to a specific Action class that handles the request. Each action class then returns a result that informs struts of what to do next. This could be forwarding or redirecting to another action or passing control to a JSP page in order to output HTML. This approach is now rather outdated, for the following two main reasons:

* It is not particularly object-oriented. Yes, each Action class defines an abstraction, but the abstraction is determined by the HTTP procotol request mechanism rather than by an object-oriented analysis.
* Unless you output HTML directly from your Java code (bad practice) you still need to learn another major technology (usually JSP plus custom tag libraries) in order to produce output HTML pages. JSP pages with custom tags are notoriously difficult to maintain and edit, especially if you want you graphic design team to do this work.

Wicket’s approach is very different. It adopts a very clean object-oriented and component based approach (much more like Swing). Each page in Wicket is a collection of components (built using the Composite design pattern). Pages and components take care of rendering themselves, either directly or via an associated markup file. When HTTP requests arrive these are converted into events that are invoked on individual components. Wicket therefore solves the two main problems with the struts philosophy as follows:

* Wicket is fully object-oriented. You work with hierarchies of components and design your application as such. There is no need to bend your oo design to fit with the request-response nature of the HTTP protocol.
* Wicket markup files are as close to pure HTML as it is possible to get. Where Wicket does introduce content into the markup it is very clean and complies with all XHTML standards (via the wicket namespace). Anyone who knows HTML can work with and edit Wicket markup files regardless of whether they know anything other than HTML or not.

HTTP Request Handling

In Struts, an HTTP request is received. Struts looks up the request path in its config file and finds the associated Action class. If configured it then extracts the request parameters into an ActionForm bean and performs some validation. The HTTP request, response and the ActionForm are then passed to the Action class. From this point on it is up to the action developer to control every aspect of the application. They must manually work with the HTTP session, they manipulate attributes in the HTTP request and the HTTP session, they must set up all of the information that they want to be available when the action is complete and so on. Finally they must return the appropriate ActionForward so that struts knows what to do next. If this ActionForward indicates that control should be passed to a JSP then the developer must also write the JSP, using all of the Struts custom tag libraries. This is a huge amount of work and VERY error prone due to the fact that names must be synchronized across THREE locations (the Struts XML config file, the Java Action class and the JSP custom tags). The whole thing is convoluted, error prone and inefficient.

In Wicket, an HTTP request is received. Wicket identifies which page the request is for and which component on the page the request is associated with. If the request is to a form then Wicket automatically extracts the request parameters, validates them, does type conversions and sets the model values on each form component in turn. It then converts the request to an event of the appropriate type and invokes the appropriate event listener on the target component. The event handling code runs, doing whatever business logic is necessary. The event handler can then choose which page to go to next. The page is instantiated (if it does not already exist) and is told to render itself. The render process visits each component in turn and asks it to render itself. Each component may render its HTML directly or may utilise an HTML markup file. The only tie up of names is that each component name in the Java component model must be mapped to an HTML element in the markup file (via a wicket:id attribute).

Reasons why the Wicket approach is much more powerful:

* Wicket components know how to handle their own events. Therefore, once you place a component on a page and write an event handler (usually a handful of lines), that’s it. If a page has 20 different components that can cause events you still need do no more than add them to the page. In struts you would either have to create 20 different Action classes or one class with a 20 way if/else if/else/switch statement plus do all the XML config!
* Wicket allows you to think of your application in terms of reusable components and events raised against these components. No more corrupting your object-oriented design to fit with the request/response nature of the HTTP protocol.
* With Wicket you write less stuff. The Java code is generally shorter than the equivalent Struts Action classes, because the reusable components have so much logic build in to them. Pure HTML with Wicket tags is much shorter and simpler than JSP with custom tag libraries. There are no XML config files in Wicket.

If you have programmed with Windows API and then with Visual Basic or Borland Delphi, the following comparison may be helpful. Programming with Struts is similar to program with Windows API: receiving raw message, decoding it and doing whatever you need to do. System does not expect any return value except acknowledgment that message was received. Windows API is procedural and is based on idea of message cycle.

On the other hand, Delphi hides Windows message cycle inside the TApplication class, and allows to build other classes around it. Raw system message is initially received by Delphi built-in classes, it is parsed and its recipient is determined. Then message is converted to an event and delivered to a proper object.

Just like in Windows application, Wicket application has resource files, which are property files for text and HTML templates for GUI. So, in a way, Wicket for web development is what Delphi for desktop development.
Servlet API & HTTP Protocol Abstraction

Struts does not hide the details of the Servlet API and the HTTP protocol. To use Struts you must be happy working with the HttpServletRequest, HttpServletResponse and HttpSession classes as well as the Struts Action, ActionForm, ActionMapping and ActionForward classes. You must also build your application around request/response principles as dictated by the HTTP protocol. This is an inherent weakness of all Model2 MVC web frameworks.

Wicket hides all the details of the Servlet API and the HTTP protocol. For many applications you will never touch any of these details. Even for very complex applications you may only need to very occasionally use one of the Wicket protocol abstraction classes, but even this is very rare. With Wicket you are working with real Java component classes, POJO business models and pure HTML markup files.

State Management

Struts pretty much requires that you take full control over state management. This is fine if you are building a massive, highly scalable, clustered application – you want granular control over everything in your HttpSession. However, for a small or medium sized application it means you have to write a lot of extra code for no reason whatsoever. Thus your application is more complex and takes longer to write.

Wicket adopts an alternative approach. By default the Wicket framework does pretty much ALL state management for you (by remembering the Page and Component states). For small and medium applications the amount of state management code you need to write yourself will be close to zero. However, Wicket also exposes a number of APIs that allow you to take control of the standard state management and implement your own alternatives if necessary. Thus, large applications can still take full control of state management, but this is not imposed on smaller applications. In fact, even when writing a large Wicket application it is common to start out with Wicket managing all of the state and then implementing custom state management solutions as part of performance tuning.

Configuration

Struts requires an XML file that defines all of the request and response mappings, all of the ActionForm objects and so on. This file can get very BIG and complex to maintain. Newer versions of Struts allow this file to be broken into separate modules. However, all this does is result in many slightly smaller but still just as complex XML files.

Wicket has NO CONFIGURATION FILES. There is a simple application configuration class that can be initialised programatically (or via Servlet init parameters) and that is it. All details of how HTTP requests map to component events, how components output their HTML and so on is contained within the Wicket application logic. Most Wicket applications can be deployed with just a handful of entries in the web.xml file – nothing more.

Wicket tits – helps you for beginers

pons — Wed, 23 Dec 2009 07:32:21 +0000

Component serves as the highest level abstract base class for all components.

Identity - All Components must have a non-null id which is retrieved by calling getId(). The id must be unique within the MarkupContainer that holds the Component, but does not have to be globally unique or unique within a Page’s component hierarchy.
Hierarchy - A component has a parent which can be retrieved with getParent(). If a component is an instance of MarkupContainer, it may have children. In this way it has a place in the hierarchy of components contained on a given page. The isAncestorOf(Component) method returns true if this Component is an ancestor of the given Component.
Component Paths - The path from the Page at the root of the component hierarchy to a given Component is simply the concatenation with dot separators of each id along the way. For example, the path “a.b.c” would refer to the component named “c” inside the MarkupContainer named “b” inside the container named “a”. The path to a component can be retrieved by calling getPath(). This path is an absolute path beginning with the id of the Page at the root. Pages bear a PageMap/Session-relative identifier as their id, so each absolute path will begin with a number, such as “0.a.b.c”. To get a Component path relative to the page that contains it, you can call getPageRelativePath().
LifeCycle - Components participate in the following lifecycle phases:
- Construction - A Component is constructed with the Java language new operator. Children may be added during construction if the Component is a MarkupContainer.
- Request Handling - An incoming request is processed by a protocol request handler such as WicketServlet. An associated Application object creates Session, Request and Response objects for use by a given Component in updating its model and rendering a response. These objects are stored inside a container called RequestCycle which is accessible via getRequestCycle(). The convenience methods getRequest(), getResponse() and getSession() provide easy access to the contents of this container.
- Listener Invocation - If the request references a listener on an existing Component, that listener is called, allowing arbitrary user code to handle events such as link clicks or form submits. Although arbitrary listeners are supported in Wicket, the need to implement a new class of listener is unlikely for a web application and even the need to implement a listener interface directly is highly discouraged. Instead, calls to listeners are routed through logic specific to the event, resulting in calls to user code through other overridable methods. For example, the IFormSubmitListener.onFormSubmitted() method implemented by the Form class is really a private implementation detail of the Form class that is not designed to be overridden (although unfortunately, it must be public since all interface methods in Java must be public). Instead, Form subclasses should override user-oriented methods such as onValidate(), onSubmit() and onError() (although only the latter two are likely to be overridden in practice).
- onBeginRequest - The onBeginRequest() method is called.
- Form Submit - If a Form has been submitted and the Component is a FormComponent, the component’s model is validated by a call to FormComponent.validate().
- Form Model Update - If a valid Form has been submitted and the Component is a FormComponent, the component’s model is updated by a call to FormComponent.updateModel().
- Rendering - A markup response is generated by the Component via render(), which calls subclass implementation code contained in onRender(). Once this phase begins, a Component becomes immutable. Attempts to alter the Component will result in a WicketRuntimeException.
- onEndRequest () – The onEndRequest() method is called.
Component Models - The primary responsibility of a component is to use its model (an object that implements IModel), which can be set via setModel(IModel model) and retrieved via getModel(), to render a response in an appropriate markup language, such as HTML. In addition, form components know how to update their models based on request information. Since the IModel interface is a wrapper around an actual model object, a convenience method getModelObject() is provided to retrieve the model Object from its IModel wrapper. A further convenience method, getModelObjectAsString(), is provided for the very common operation of converting the wrapped model Object to a String.
Visibility - Components which have setVisible(false) will return false from isVisible() and will not render a response (nor will their children).
Page - The Page containing any given Component can be retrieved by calling getPage(). If the Component is not attached to a Page, an IllegalStateException will be thrown. An equivalent method, findPage() is available for special circumstances where it might be desirable to get a null reference back instead.
Session - The Page for a Component points back to the Session that contains the Page. The Session for a component can be accessed with the convenience method getSession(), which simply calls getPage().getSession().
Locale - The Locale for a Component is available through the convenience method getLocale(), which is equivalent to getSession().getLocale().
String Resources - Components can have associated String resources via the Application’s Localizer, which is available through the method getLocalizer(). The convenience methods getString(String key) and getString(String key, IModel model) wrap the identical methods on the Application Localizer for easy access in Components.
Style - The style (“skin”) for a component is available through getStyle(), which is equivalent to getSession().getStyle(). Styles are intended to give a particular look to a Component or Resource that is independent of its Locale. For example, a style might be a set of resources, including images and markup files, which gives the design look of “ocean” to the user. If the Session’s style is set to “ocean” and these resources are given names suffixed with “_ocean”, Wicket’s resource management logic will prefer these resources to other resources, such as default resources, which are not as good of a match.
Variation - Whereas Styles are Session (user) specific, variations are component specific. E.g. if the Style is “ocean” and the Variation is “NorthSea”, than the resources are given the names suffixed with “_ocean_NorthSea”.
AttributeModifiers - You can add one or more AttributeModifiers to any component if you need to programmatically manipulate attributes of the markup tag to which a Component is attached.
Application, ApplicationSettings and ApplicationPages - The getApplication() method provides convenient access to the Application for a Component via getSession().getApplication(). The getApplicationSettings() method is equivalent to getApplication().getSettings(). The getApplicationPages is equivalent to getApplication().getPages().
Feedback Messages - The debug(String), info(String), warn(String), error(String) and fatal(String) methods associate feedback messages with a Component. It is generally not necessary to use these methods directly since Wicket validators automatically register feedback messages on Components. Any feedback message for a given Component can be retrieved with getFeedbackMessage().
Page Factory - It is possible to change the way that Pages are constructed by overriding the getPageFactory() method, returning your own implementation of IPageFactory.
Versioning - Pages are the unit of versioning in Wicket, but fine-grained control of which Components should participate in versioning is possible via the setVersioned(boolean) method. The versioning participation of a given Component can be retrieved with isVersioned().
AJAX support- Components can be re-rendered after the whole Page has been rendered at least once by calling doRender().you can use the live link for ppt downloads

wicket PPT for beginers download,

Here is the reference for the standard Wicket GUI components: Component Reference

Wicket Based sites

pons — Mon, 21 Dec 2009 03:38:47 +0000

* FITCOMPLEX.SK FITCOMPLEX is portal about healthy lifestyle, nutrition and exercise. (Slovak language)
* InLaconia.gr InLaconia.gr is a travel and business guide for Laconia in Greece.
* InsideWood InsideWood contains brief descriptions of fossil and modern woody dicots (hardwoods) from more than 200 plant families, and is searchable by an interactive, multiple-entry key. There are over 34,000 images showing anatomical details.
* BuscaBooks Buscabooks is a amazon associate web site for brazilian portuguese language users.
* Abstract Database Online serach engine for published congress abstracts
* Fabulously40 40+ woman’s social network. Rails site gone wicket.
* MeetMoi Location based mobile dating.
* Nemours One of the nation’s largest children’s health systems
* NextDoor Handyman recruiting and yellow pages service for various Domestic Services
* Tuntinetti Time tracking online
* seeMyWhere Allows you to create a public page that tracks your location automatically
* Roo10 Roo10.com is a social news, bookmarking and ratings site that allows you to share, rate and discover new content. You can post content here on practically anything – both from the web the “real” world. Users of the site can then give your posts a rating out of 10.
* 8vents Message, Photo, File sharing service.
* Ninan Binary Download Usenet Client. Struts application currently being converted from struts to wicket. Access to wicket is currently though svn. (free and opensource project)
* Virtual Ventures Preview software developed by Fortune 500 companies, predict their success for commercialization, earn cash. Fully developed in Wicket and Spring.
* Pink Laptops Pink Laptops.
* Coderspiel Blog of N8han written using Wicket and databinder
* Artifactory Artifactory is a maven2 proxy based on Wicket
* JTrac JTrac is an open source and highly customizable issue-tracking web-application written in Java.
* morons.org Morons.org is a community website based on tally-ho
* Used Cheap Laptops Used Cheap Laptops.
* tally-ho Forum/Community software powering morons.org
* TexasHuntFish Community site for Texas sportsmen. Currently being converted from ColdFusion to Wicket – about half way there.
* Teachscape A professional learning system.
* Servoy A RAD environment which uses Wicket for web interface generation
* Voicetribe Voicetribe adds online commentaries to your favorite DVDs.
* Eventful Eventful allows you to manage your event with simplicity and ease.
* Irrigator A simple web interface for controlling water taps in an irrigation system
* Burgerweeshuis An open source CMS for pop venues, currently only dutch
* Szeretgom.hu A Hungarian community web site built on wicket for the city of Esztergom
* Track Detective A site for GPS track analysis and manipulation
* Basisregister Bedrijven Amsterdam. An internal site to cross check company data over several databases for the municipality of Amsterdam.
* Papernapkin.org A code pastebin with syntax highlighting.
* Alliance Communications Managment Alliance uses wicket for internal sites which provide reporting and bug tracking for internal software systems.
* Vocus student information system Topicus created a web based student administration system for highschools. The application is not publicly available.
* Jobindsats.dk Danish government employment statistic report generator.
* WebiCal A Web application to view and edit multiple iCalendars
* Sell@Market Is a web-based solution that helps to protect your gains and cut down your losses on stock trading.
* GenieTown GenieTown is building a unique online community of customers and service providers. The site is designed to restore the lost experience of Main Street, where business was conducted in a personal way, the resources were local, and reputation was paramount.
* Finan Finan is a financial analysis tool and now features a web based solution for their win32 deplhi client application built using Wicket
* jWeekend (OO & Wicket Training Courses) A Wicket site (nice/simple AJAXified cart on the “Booking” page).
* datawink an online chart pattern recognition search engine
* Avigo.de Atlasreisen.de AdacReisen.de Der.de Dertour.de Meiers-WeltReisen.de Tourism portals built by Wicket-Hibernate-Spring trio
* B-Side B-Side is a distributor and online marketplace for independent films
* TeachUs Open Source booking system designed for teachers with one-to-one tuition. Online demo (login with leif/leif). Project website
* javaMix Java news aggregation site
* Vegas.com Travel and entertainment site for Las Vegas shows, hotels, tours, club passes, etc.
* beTurtle ‘Green’ social networking and information portal.
* My Picture Town Photo sharing service by Nikon
* IndyPhone Customize your mobile phone by creating your own logos.
* jalbum.net Photo album hosting is Wicket and all of site was migrated from JSP.
* Me.dium.com Social browsing company bringing a unique experience to the online world.
* yeigo.com Mobile VoIP solution, instant messaging (click signup for the wicket part).
* Fenlab Nigeria Limited Agents of Hobart Foster and Other cooling equip. manufacturers in Nigeria
* uTIPu Record and share your screen in a video.
* Davano Collaborative storytelling and Play-by-post-RPG supporting system. Rewritten from from PHP to Wicket+Spring+Hibernate.
* s q u a r e e y e s i c o n h a r m o n yGallery of over 1550 downloadable tv icons for the Harmony One remote.
* The National Will Database A Repository of Wills, Executors and Solicitors. Wicket 1.3, Spring and Hibernate. Thanks to Qwicket and all the Wicket team.
* Tenant Checker A commercial service for UK landlords. Uses Wicket, Spring and Hibernate. Short blog entry announcing its arrival here Enterprise Technical Architecture
* Wego Travel search engine. Using wicket for flights schedules module
* iSport.eu Football (soccer) news aggregator. Uses Wicket, Spring, Hibernate and Derby, see the blog entry for details
* IslamicDesignHouse A shopping site for innovative and contemporary islamic goods such as jilbabs. Uses Wicket, Spring and Hibernate.
* Lyhoo A personalized product search, user needs matching and alerting site in Chinese. Migrated from Spring MVC.
* LINK ATM Locator Search for ATM’s in the UK. Thanks to the Wicket Team and nmwael+WicketStuff for the GMap code.
* Songtexte.com A social network for music geeks including lyrics, videos, …. Uses Wicket, Spring, Hibernate.
* paulimot.de A shopping site selling turning and milling maschines and all needed accessories, … Uses Wicket, Spring and Eclipselink for the frontend as well as the administrative shop interface.
* OjoDojo A funny picture website that lets users organize and rank the best photo memes on the internet. Uses Wicket, Spring, iBatis.
* hackystat-ui-wicket Wicket-based interface to Hackystat
* syntevo.com SVN client: SmartSVN, CVS client: SmartCVS
* Rate A Rear – Don’t view on a computer at work!
* mygoods.at – food price comparison
* tipSpot – Your social city guide
* HussainiAbdu – Personal Website providing educational information and resources.
* SVNsite Subversion Hosting – commmercial SVN hosting service built on top of Wicket, JPA and Wicket RAD.
* Loma Linda Physicians Search – a physicians search module for Loma Linda University Medical Center developed in Wicket and integrated with TeamSite. Developed by Mystic
* LeapFrog Learning Path – Learning Path helps parents interact with their child’s progress on LeapFrog devices such as Tag, Leapster2, Didj, and Crammer. Mystic developed and maintains the Wicket-based application.
* Estobel’s website – Brazilian company of upholstered furniture (wicket, spring and hibernate)
* Profile2 – A Web2-styled Wicket-based Profile tool for Sakai.
* Statistic Charts – A dynamic charts mashup with very nice visuals. Uses Wicket, Google Visualization, Spring. A short blog description here.
* Tip Links Travel links directory. Wicket, Spring, Google Visualization, Hibernate Search, Lucene. A short blog description here
* KinoEstet Responses, opinions about films, and films ratings (russian language)
* Gesvalfi, Property Management in Valencia Webpage of Gesvalfi, Property Management, a company in Valencia who’s main purpose is the administration and management of neighbour communities.
* Citikey Free local business directory for the UK and Ireland
* CompressLink Free URL shortening service
* Gold Lock
* Devproof

DataBinders – A tool kit for wicket and its data binding applications

pons — Mon, 14 Dec 2009 16:58:57 +0000

DataBinders is a programming toolkit for data–driven Wicket applications. Generally preferring creativity over convention, Databinder’s aim is to facilitate database programming for the Web that is straightforward, pleasant, and flexible.

updated to Wicket 1.3.5 and Hibernate 3.3.1.

you can look at the overview of wicket databinder here

http://databinder.net/wicket/show/overview/

The databinder for database binding application Examples are shown here. Its a maven based application

http://databinder.net/wicket/show/overview/about-examples

Wicket Web Beans

pons — Mon, 14 Dec 2009 16:24:53 +0000

Wicket Web Beans
Introduction to Wicket Web Beans

Wicket Web Beans (WWB) is an Apache Wicket (http://wicket.apache.org) component toolkit for displaying and editing POJOs that conform to the JavaBeans specification. Web pages are automatically generated based on bean properties and certain conventions. If necessary, the layout, editability, and actions of these pages can be customized on an exception basis. In other words, the toolkit normally does what you’d expect, but when it doesn’t, you can override its behavior.

At the highest-level, the net.sourceforge.wicketwebbeans.containers.BeanForm component provides rich AJAX form functionality. The form is embedded in a Page designed by you. This allows you to create customized page designs. Also, this allows multiple

BeanForms to be incorporated on a single page. At your choosing, other lower-level components may be used independently of BeanForm (e.g., BeanGridPanel). WWB does not try to force you into a certain way of doing things, but BeanForm makes it very convenient to implement a bean-based form if you don’t want to go to a lot of extra work. You focus on the model (beans), WWB handles the user interface.

Fields within a form are dynamically sent back to the server-side bean as they are changed, which eliminates the typical submit cycle. This makes WWB act more like a rich client application and less like a standard forms-based application.

Requirements

WWB currently requires:

* Maven 2.0 is required to build. A binary WAR file (wicketwebbeans-examples.war) containing all of the dependent jars is available.
* Wicket 1.3.0-rc1 (http://wicket.apache.org) – dependency managed by Maven. Apache Wicket 1.2.6 is also supported in a separate branch.
* Apache Commons BeanUtils (via Maven http://maven.apache.org)
* Java 5+. WWB has been developed and tested mostly with Java 6.

Simple Example

Let’s take a look at a simple bean from the examples: net.sourceforge.wicketwebbeans.examples.simple.TestBean

This is a Java Bean compliant POJO. As most people know, getters start with “get” or “is” and setters start with “set”. Java Beans also require a public no-argument constructor, which we have. All beans must be Serializable by Wicket convention.

This bean also implements PropertyChangeListeners and Events. This is an optional part of the Java Beans spec. However, if your bean implements add/removePropertyChangeListener(), BeanForm will automatically register itself as a listener to your bean. In this example, we’re going to use PropertyChangeEvents to notify BeanForm when dependent properties change.

If you don’t implement PropertyChangeListeners, BeanForm already knows if a single property changes from a change on the form. For example, setFirstName() automatically changes the input value to upper case. BeanForm knows to refresh this field on the form because the user changed it. If you type “xyzzy” in the First Name field and tab or click away from the field, the field is sent to the bean and the field is dynamically refreshed to it’s new value “XYZZY”.

Before we get too deep, let’s take a look at the Wicket page (net.sourceforge.wicketwebbeans.examples.simple.SimpleBeanPage) and HTML:

Simple Bean Page

package net.sourceforge.wicketwebbeans.examples.simple;

import net.sourceforge.wicketwebbeans.containers.BeanForm;
import net.sourceforge.wicketwebbeans.model.BeanMetaData;

import org.apache.wicket.markup.html.WebPage;

public class SimpleBeanPage extends WebPage
{
public SimpleBeanPage()
{
TestBean bean = new TestBean();
BeanMetaData meta = new BeanMetaData(bean.getClass(), null, this, null, false);
add( new BeanForm(“beanForm”, bean, meta) );
}
}

You can see this is pretty simple. There is only a single component added to the page – “beanForm” – which is an instance of net.sourceforge.wicketwebbeans.containers.BeanForm. You can see in the constructor that we create an instance of TestBean which is passed to BeanForm. We also create an instance of net.sourceforge.wicketwebbeans.model.BeanMetaData. BeanMetaData reflects on the TestBean class to derive the fields and actions for the form.

Note that you can also pass a Wicket IModel that contains your bean, rather than the bean itself, to BeanForm. If the bean is a List, or the IModel contains a List, the results will be displayed as a data table.

If you bring up this page in a browser (see RunningSamples), you will see something like:

Eclipse:/WicketWebBeans/doc/wiki/images/SimpleBeanScreenShot.png

Note that “Result” is not editable because there is no setter method on the bean. Also, if you type numbers into Operand 1 and Operand 2, you’ll see that the Result field automatically is calculated and updated. The calculation is done by TestBean and the PropertyChangeEvents are notifying WWB to update the result field.

As we mentioned, BeanMetaData represents the metadata for a bean properties and actions. By default, the metadata originates by convention:

Label names for properties are derived from the property name. E.g., “customerName” becomes “Customer Name”; “address2″ becomes “Address 2″ (or from the JavaBean BeanInfo “displayName”).
Field components for the Java primitive/wrapper types, enum types, java.util.Date and java.util.Calendar thier sub-classes, and java.util.Lists are pre-configured.
All JavaBean properties are displayed. Non-JavaBean methods are not displayed.
All fields are editable if viewOnly is false (see the BeanMetaData constructor). Otherwise they are all view-only.
If a property is not writable, it is displayed view-only.
If your beans use JPA or JDO, other property aspects can be controlled by annotations available in these APIs.
Actions are derived from action methods defined on the component (e.g., the Page). See Actions below.
All fields are displayed in alphabetical order by property name.
All fields are displayed in a single page. (Known as the “default tab”, but the tab is hidden).

Field types are deduced from the property’s Java type. The mappings from the property’s Java class to the net.sourceforge.wicketwebbeans.fields.Field type is done by net.sourceforge.wicketwebbeans.model.ComponentRegistry. ComponentRegistry has mappings for most common types and more types can be added if necessary. Also, Field types may be overridden for a specific property in the “beanprops” file, which we’ll discuss later.

Up to my Knowledge WWB is based on properties , there is also Wicket web beans data binder for your reference I will give you the link if you really interested to go further

http://wicketwebbeans.sourceforge.net/wiki-html/SimpleExample.html