In the next step, we will open the HeaderPanel. Open HeaderPanel. Notice that it has the same name as the Java file we have just looked at. It is found within the same package structure. This is what it looks like:. This is how you specify where a widget should be rendered in the HTML side of a web page.
Hold down the Ctrl key and move your mouse over the value of the wicket:id attribute in the span tag. Notice that the value turns into a hyperlink:. In this way, you can navigate quickly and efficiently between the two sides of Wicket components. Footer Panel. The structure of the footer panel is the same as the header panel, described above. Right-click the project and run it. The sections below also introduce you to various supporting features that the NetBeans Wicket plugin makes available.
In this section, we create our first widget in Wicket. On the Java side, the widget is created. On the HTML side, it is rendered. As shown previously, navigation between the two sides is made possible via a hyperlink. Open HomePage. You see the dialog below:. Next, open HomePage. Save the files.
Refresh the browser and you will see the Wicket Label, rendered in the HomePage. You can create placeholders, just like the tag you created in the HomePage. While the web designer designs the web page, you can work on the Java side and create the widgets completely independently.
One of strengths of Wicket is the concept of "reusable components". Here, in this section, we use a wizard to generate a panel, which again has a Java side and an HTML side.
We will create this panel so that we have a banner that we will reuse in our web pages, so that the banner is consistent across our web site. We will see how easy it is to add a panel to a web page. Right-click the com. Under Categories, choose Web. Under File Types, notice the following templates:. Notice that we now have two new files in our package, BannerPanel. Between wicket:panel tags, a Wicket placeholder is found. Hold down the Ctrl key, move the mouse over the value of the Wicket id, and click the hyperlink that appears.
The BannerPanel. Our panel, while simple, is actually complete already. Lets add it to the home page. Next, we need to render the panel. Run the project again. Notice that the panel is displayed, exactly where the HTML file specified it should be rendered:. In Wicket terminology, a panel is a reusable component. Exactly as shown in this section, you can reuse the panel as often as you like and in as many web pages as you fancy.
Below, you are shown how to change the BannerPanel to include an AJAX autocomplete widget, instead of the label widget you created previously. Click OK and make sure the BannerPanel class uses the following import statements:.
Refresh the browser again and you will have an AJAX autocomplete field. Finally, we will provide a link from the home page to the movie list page. In the end, the home page will look like as shown in Screenshot: Home page containing a title and a link to the movie list page. Other than the project files themselves, we also need a web server environment in which to execute our application.
Setting up a correctly configured project can prove to be a difficult task, especially for a beginner. Therefore, we will use the following files prepared specifically for this tutorial. This archive contains the files needed for a very basic Wicket application. Extract it anywhere on your computer. This archive contains the Wicket libraries on which our application code depends.
Extract it under the folder where you extracted the quickstart. This archive contains the logging libraries needed by Wicket. Extract it to the same folder as the wicket. This archive contains the web server which will provide us with the environment that can run our application. If you are using Eclipse, you can import the project from the wicket-quickstart directory. Most of the files that we are going to work on are in the src folder. Since the Java classes in the quickstart archive are in the Java package wicket.
The HTML web page templates are also in that folder. The starting point for a Wicket application is the application class. In our example, this is the WicketApplication class. Note that, this class extends the WebApplication class from the Wicket framework line 6 and defines a getHomePage method line 8 for specifying what the initial page of the application will be. In our example, the initial page will be an instance of the HomePage class line 9.
Any extra initialization for the application should be handled in the init method of the application class lines In Wicket, we have to write two files for every page in the application: one is an HTML file that contains the template of the page, and the other is a Java source file containing the components that control the dynamic elements in the template. The name of the class and therefore the base name of the Java source file has to be the same as the base name of the HTML template file, as in SearchPage.
Since our application class refers to a HomePage class as the initial page for the application, we need to implement that class. A component can broadcast a message without needing to know who will receive the message. When a component is interested in a particular type of message, it can simply register to be notified when that message is broadcast.
A component might broadcast a critical update event with payload to all other components on the page in this manner:. Wicket provides helpful utilities to make writing unit tests simple.
We have a web page with a CRUD interface: a table with baby names and delete buttons. A form with a text field and button for adding new rows to the table.
We can write a test that will render the page, simulate a user filling out and submitting the form, ensuring the table is updated correctly, simulate the user pressing the delete button, and so on. This can all be accomplished using pure Java code and JUnit without resorting to Selenium, Puppeteer or similar libraries.
Are you deploying different versions of your software to multiple clients with test, staging, and production environments? Are clients picky about features they want to release to each environment? Where Wicket really shines is, when it comes to dynamic rendering of User Interfaces.
For example based on meta data or an abstract meta model like we do it in the Dynamic Application Framework. The framework requires initial, not to be underestimated effort to yield performance. Wicket was a breeze compared to overcomplicated and bloated JSF 1. Nowadays I would evaluate if there are other web frameworks out there which do fit my needs, before I used Wicket. I still love the framework, because I like Java and Web Development, but it has its gotchas when it comes to modern user interfaces.
One needs a lot of know-how to create fancy, user friendly stuff. Apparently, this is not my last post about Wicket. There were more lessons learned during the past three years! Wicket in Action - a comprehensive guide for Java developers building Wicket-based web applications. Share via email Subscribe to blog alert. Developer Apache Wicket — three years of lessons learned.
0コメント