We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Introducing Apache Wicket

00:00

Formal Metadata

Title
Introducing Apache Wicket
Alternative Title
apache wicket
Title of Series
Number of Parts
64
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Apache Wicket is a component oriented Java web framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Wicket makes developing web-apps simple and enjoyable again. This talk provides a short introduction to the framework's concepts: components, behaviors and models. We'll take a short look at integrating with Spring and integrating with JQuery. For the test infected we'll cover testing your web pages with Wicket's internal test framework. But most importantly we'll take a look at the new Wicket release 1.5 and see what has changed for the better and worse
Apache WicketEvent horizonPoint (geometry)Software frameworkMobile WebForm (programming)Online gameCodeWebsiteWeb 2.0Selectivity (electronic)Android (robot)Greatest elementProduct (business)WindowInternet forumCategory of beingoutputJava appletWhiteboardDrag (physics)Server (computing)Open setWeb applicationAntivirus softwareDifferent (Kate Ryan album)Cartesian coordinate systemFeedbackField (computer science)Message passingProcess (computing)Coma BerenicesVideoconferencingConnectivity (graph theory)Vector potentialFreewareNumbering schemeBuildingPasswordOpen sourceFigurate numberMereologyReal numberDot productEmailCuboidBitCASE <Informatik>Multiplication signSign (mathematics)Projective planeCommutatorComputer animationXMLLecture/Conference
Form (programming)Ruby on RailsJava appletMarkup languageWeb applicationMessage passingWeb-DesignerFree variables and bound variablesWebdesignCodeVelocityWeb pageWeb 2.0FeedbackError messageConnectivity (graph theory)ResultantIdentifiabilityCore dumpField (computer science)TouchscreenClient (computing)EmailPasswordWeb browserComputer fileoutputTemplate (C++)CuboidGame controllerStatement (computer science)Imperative programmingSign (mathematics)Process (computing)Row (database)CodeWorkstation <Musikinstrument>BackupFile systemSmith chartSoftware frameworkWeightBuildingProjective planeCartesian coordinate systemMereologyReal numberLecture/Conference
Spring (hydrology)Core dumpField (computer science)Connectivity (graph theory)Library (computing)WebsiteVisualization (computer graphics)String (computer science)Endliche ModelltheorieExtension (kinesiology)outputFunctional (mathematics)Computer programmingDatabaseCartesian coordinate systemNumberProjective planeJava appletServer (computing)VelocityLatent heatEvent horizonINTEGRALMarkup languageCategory of beingAdaptive behaviorTemplate (C++)Web applicationContent (media)Context awarenessAuthorizationWeb 2.0Software frameworkMultiplication signModule (mathematics)InjektivitätLink (knot theory)LogicComputer filePower (physics)Transformation (genetics)Domain nameDifferent (Kate Ryan album)Instance (computer science)AdditionProcess (computing)Workstation <Musikinstrument>SurfaceObject (grammar)Moving averageLevel (video gaming)Control flowMobile WebLoop (music)Price indexRow (database)QuicksortLecture/Conference
Line (geometry)Group actionRadical (chemistry)SpacetimeCuboidWeb pageMultiplication signRevision controlLecture/Conference
Apache WicketPort scannerInformationCuboidCartesian coordinate systemType theoryDensity of statesWindowRadical (chemistry)Server (computing)Web browserLecture/Conference
Moment (mathematics)CodeWeb pageProjective planeControl flowPrice indexSpring (hydrology)INTEGRALLecture/Conference
IdentifiabilityConnectivity (graph theory)Multiplication signLink (knot theory)Web pageNumberMarkup languageWebsiteLecture/Conference
Link (knot theory)Software frameworkFunction (mathematics)Software developerIdentifiabilityField (computer science)Asynchronous Transfer ModeJava appletCategory of beingEndliche ModelltheorieMultiplication signCountingNumberConstructor (object-oriented programming)Error messageDefault (computer science)Process (computing)FamilyConfidence intervalWeb pageCartesian coordinate systemLecture/Conference
Markup languageElectronic visual displayCache (computing)Message passingError messageConnectivity (graph theory)Software developerSoftware testingDebuggerAsynchronous Transfer ModeCartesian coordinate systemTracing (software)Computer programmingStandard errorWeb pageDynamical systemPointer (computer programming)Point (geometry)Order (biology)MereologyProduct (business)Lecture/Conference
Link (knot theory)Link (knot theory)Connectivity (graph theory)Error messageDegree (graph theory)Web pageHome pageGreatest elementCountingMarkup languageMessage passingWindowDebuggerHierarchyLecture/Conference
Interactive televisionCodierung <Programmierung>NumberBuildingCycle (graph theory)EmailSoftware bugWeb pageWeb browserIntegrated development environmentKeyboard shortcutException handlingCodeUnit testingProgrammer (hardware)Software frameworkEndliche ModelltheorieError messageConnectivity (graph theory)Different (Kate Ryan album)Projective planeField (computer science)Open sourceLatent heatExtension (kinesiology)PasswordJava appletSocial classCartesian coordinate systemValidity (statistics)Library (computing)Finite-state machineSoftware testingMarkup languageOcean currentCore dumpOrientation (vector space)CountingCombinational logicDirection (geometry)Computer fileUniform resource locatorLink (knot theory)Flow separationFunctional (mathematics)Digital electronicsExecution unitPoint (geometry)Shooting methodSpring (hydrology)Process (computing)User interfaceHypermediaServer (computing)Physical lawTelecommunicationBoom (sailing)Revision controlPRINCE2Heegaard splittingSurfaceOnline helpWebsiteLecture/Conference
Event horizonHand fanProcess (computing)Computer clusterJava appletSoftware frameworkCountingLink (knot theory)CASE <Informatik>Figurate numberBitPoint (geometry)Patch (Unix)Web pageComputer wormException handlingMessage passingCore dumpPlastikkarteRing (mathematics)Electric generatorBus (computing)Connectivity (graph theory)Cycle (graph theory)Cartesian coordinate systemInterface (computing)Social classOpen setType theoryObject (grammar)Conjugacy classBroadcasting (networking)Set (mathematics)Function (mathematics)Parameter (computer programming)Markup languageArtistic renderingCodeUniform resource locatorPerspective (visual)Inheritance (object-oriented programming)Web 2.0Functional (mathematics)Envelope (mathematics)Lecture/Conference
Server (computing)Different (Kate Ryan album)InformationSurfaceConnectivity (graph theory)Client (computing)Web pagePoint (geometry)PhysicalismMechanism designJava appletSound effectComplete metric spaceExecution unitMultiplication signLine (geometry)MeasurementDigital photographyMarkup languageBus (computing)Human migrationProcess (computing)INTEGRALHand fanWindows RegistryEvent horizonPlanningLibrary (computing)Sign (mathematics)IdentifiabilityWordThomas BayesProgramming paradigmElectronic mailing listError messageTouch typingEndliche ModelltheorieComputer programmingSingle-precision floating-point formatThread (computing)GUI widgetData miningWeb browserProjective planeComputer wormUnit testingCodeMessage passingCompilerIntegrated development environmentFlow separationPlug-in (computing)Cartesian coordinate systemDataflowDefault (computer science)Dynamical systemLecture/Conference
XML
Transcript: English(auto-generated)
Okay, I'll be talking about Apache Wicket, a component-oriented web framework. This is the agenda, I'm going to introduce Apache Wicket a bit, and I'll be talking
about our upcoming release, 1.5, and then I'll take some questions. First about me, I'm Martijn Dashorst, I work for Tobicus, a Dutch-based company building web applications. I'm the chair for Apache Wicket, that means that I'm mostly sat on, people like to sit
on me, like the board of Apache and my fellow committers. I commit sometimes to the Wicket project, I'm an Apache member, and I wrote a book about the framework I'm going to talk about.
The introduction. What is Apache Wicket? It's a component-oriented web framework using just Java and HTML. It's open source, otherwise I wouldn't be standing here. Apache license, so anybody can do with it whatever they want. It was created in 2004, I already said it's a Java web framework, it's component-oriented,
and you can find it at the URL at the bottom. So who's using Wicket? Anybody here using Wicket? Show of hands. Not that many, so okay.
Don't feel lonely, there are other people using Wicket as well. Adskill, I never heard of it, it's a German ad company, it's in the Alexa top 2000 of worldwide websites, I never heard of it but apparently it works pretty well.
Other websites, mobile Walmart, the biggest American retailer in the world. A dating website, something for song texts, a portfolio for sharing your photos, if you're
a woman and over 40 years old, there's this nice forum for you with lots of interesting articles. For the Dutch people here, eropout.nl, it's a trip selection website, it's Wicket-based.
Other Dutchies, Marco Bosado, a very famous Dutch artist, his website is also built with Wicket. If you want to go to Mexico, this website is built with Wicket. If you need to go more formal with a nice tie, you can buy them with Wicket.
In the late hours you can play an online game using Wicket. You can drink wine while you're playing. If you run Windows, anybody runs Windows? Wow!
One! You can buy Antivirus products with Wicket. And finally, if you want to go to Las Vegas, you can book your trip here. But I can't tell you anything about it because everything that happens in Vegas stays in Vegas.
A couple of quotes from our users. mobile.barmot.com supports three categories of mobile devices using the same Java code and only the HTML is very different. You can imagine that Android and iOS mobile phones are pretty much in the same ballpark but Windows Mobile 6 is really a drag with parsing HTML so they need to serve different HTML for that.
The guys from Vegas.com, they also launched Mexico.com last year and they just reused their existing application and created a whole new website for booking vacations and holidays in Mexico.
They found that reuse of their code was tremendous. So when I told you what Wicket was, it's a component-oriented web framework and uses just HTML.
So let's explore that a little bit. Let's create this signup form. I took this example from RailsCast. Anybody familiar with RailsCast? It's a very nice online website where someone makes videos, screencasts of building small Rails components.
Usually five, ten minutes times. It's really nice to get a feel of Ruby on Rails. So if you want to make this in HTML5, the form would look something like this. You have a header, a form within it, some place to get feedback messages from your users,
an email field, a password field, and a confirmation box and a button to submit it. Using Ruby on Rails, it would look something like this. You have a special tag for Ruby code, where you have, for a user, you create a form,
and if there are any errors, you display this part, et cetera. This looks a lot like JSPs. Anybody use JSPs? Ah, that's considerable, people.
So do you enjoy it? So if you go back to the HTML, if you open this up in a browser from the file system, it doesn't look anything like the signup form.
It's completely empty, except for you see the text signup, and after that you don't see anything. It's completely blank, because the browser doesn't know anything about these Ruby statements. Similarly with JSPs, all this stuff that's important for Java is not shown in the browser. So if you open up this preview in your browser, it looks exactly like that.
Now, with Wicket, we use that markup. We augment the markup with a couple of placeholder tags, where we tell Wicket to do something. And if you open this up in the browser, it still looks like the same form.
So Wicket uses this idiom to get at the tags, the markup that needs to be manipulated. In summary, there are two ways to look at your markup for building web applications.
You have imperative markup, where you have code and markup intersected. It's used a lot by Ruby and Rails, JSP, Play Framework, Velocity Templates, and it's great for web developers.
I always hear, when people complain about Wicket, well, you can't do anything in the markup, but I'm used to. So there are definitely a lot of folks that enjoy working like this. And it gives quick results. If you run it, you can work pretty fast.
You have a website running. I find it a problem that code and markup are not separated. So conversely, we have declarative markup, and this is used by Wicket, pioneered by Tapestry, and Facelits, a JSF framework, uses this as well.
But this is great for web designers. The people who mock up your web application, the screens in Photoshop, you can go from Photoshop to HTML. You can show that to your clients. Once the client says, wow, that's great. It's really snappy.
It feels like you're almost complete. Then you go and create your web application from it. So you take that HTML, you put it in your Eclipse or NetBeans project, and you augment it with the Wicket identifiers. And you start writing Java code. With Wicket, code and markup are completely separated.
Unless, of course, you're doing JavaScript in the browser, that's, of course, inside your markup. So just Java. If you look at the signup form, this is again the Ruby on Rails template.
You see a lot of code in there, and there's also a controller at the back that receives the form input. If you wanted to create something like that using Wicket, it would look something like this. First, you create a form component, and a form receives an unsubmit message. Within that unsubmit, you can do your thing,
like saving the user, booking a trip, that kind of stuff. You add the form to the page. If you want to provide feedback to the user, it's nice to have feedback messages shown. So we create a feedback panel,
that's Wicket core component that displays error messages. We can tell it that it should only be visible when there are feedback messages, similar to the if-then-else construct in the Ruby on Rails page. And we add it to the form.
Next, the fields. So we have an empty email text field, we add it to it, we add a password field, and we add another confirmation password field. And that's what you need to do in Java for creating this form. So it's just Java?
Now really, don't fall asleep, please. I'll just talk louder. Just Java, no logic in your markup, just in your Java files.
Components are objects, so you can instantiate them using just new, or you can subclass components with extents. You can use object-oriented techniques in your programming. You can create encapsulated components that work on their data and give events to other components, et cetera.
And we did our best to minimize the number of XML files you need to provide with Wicket, exactly one, and that's mandated by the server specification. If you're running on JEE before number six.
So, no XML. Quickly, the concepts. We have components. Components manipulate markup. They render content. For instance, a label doesn't manipulate its markup itself, but it renders the content you provided. If you have a label that should show a name,
it just renders the name. Components can also receive events. Like a link, if you click on a link, you get an onClick event. Wicket has models, and with models you can provide data to components. Components need to work on data.
A label needs to know what it needs to display. A link that deletes a user from your database needs to know what user to delete. Models also store data for components. For instance, an input field needs to store the input provided by the user.
But it also needs to render the value that's going from your database. So that's a two-way street. Models can also transform data. You can receive a string for your database and transform it into a phone number, or vice versa.
And you can use models to retrieve your entities from the database. Examples are a model and a property model. The last concept I wanted to introduce are behaviors. Behaviors are decorators or adapters for components.
They can manipulate the markup of a component without the component knowing about it. They can receive events. You can receive an onClick in a behavior. You can add Ajax functionality to components that are not Ajax aware. For example, you can create a label
that just increases every time it's rendered using an Ajax self-updating timer behavior. You add it to the label, and the label will continuously update itself. So, getting started.
If you go to Wicket, if you think, Wicket, it's an arcane framework, nobody knows about it. There's actually quite a community around it. We have, of course, our own project, Apache Wicket. It contains our core stuff, and it's all Apache licensed. We have a Wicket stuff project, which is a community project where anybody can sign up
and publish their Wicket components, libraries. There's Steam for Wicket. There's YQuery and jQuery integration. Lag before Wicket for quickly getting started with Wicket applications.
Apache ISS, domain-driven design web framework that has a module 4 for Wicket. It's currently incubating in Apache. Jolira tools, that's a component library for creating stateless web applications with Wicket. That powers the mobile website for Walmart
and Visual World Wicket, also lots of standalone components that are not dependent on a particular JavaScript framework. Apache Wicket projects, we have core. That's the core library where all the functionality exists to make your Wicket applications.
Extensions contains additional components, richer components, things you don't need directly to create your own application, but most people typically use extensions as well. We have a quick start to get to running fast. Integrations with Spring and Use,
a data picker, a project to use velocity templates, markup templates in your Wicket application, small authorization and roles project to create secure applications, and finally, the examples display
almost any component that's hosted at Apache. When I told you that Wicket stuff is community hosted, well, you can see how many projects there are. These are all top-level projects. There are some sub-stuff as well.
There's, for example, a Java EE inject, so for the dependency injection JSR. So if you want to get started with Wicket, we provide a nice page, the quick start page, and you can generate a command line for Maven.
Who uses Maven? Okay, quite a lot. Who enjoys it? Ah, the half about it. Okay. I enjoy it most of the time. So if you go to this page, you can fill in a couple of things,
your group ID, your artifact ID, the Wicket version you want to use, and you copy-paste the command line. So you open a DOS box or a terminal window. You paste in that command, and you really don't want to type this in.
You press enter. Maven does its thing. It starts logging like crazy. And you can then run the quick start application with jetty.run. You press enter, you get this nice console, and finally it says, started jetty server.
You open a browser. You go to localhost, colon, 8080, and you get presented with this nice helpful page. And from that moment on, you can start hacking on your Wicket code. It's quite a nice project to start developing or to spike small stuff.
If you want more, there's this project called LegUp, and they provide integrations with quick starts for Wicket with Spring, Juice, JDBC, GPA, Hibernate, and Scala. So if you want to learn more,
there are a couple of books in German, Japanese, and English. And I think there's someone trying to translate one of the books into Portuguese. So if you want to learn more about these books, it's there at the website.
Some quick examples. First, Hello World, the infamous example. So if you want to display the Hello World text, we create some markup displaying Hello World.
We want to replace the text Hello World. So first thing we do to make it Wicket-enabled is to add the Wicket component identifier. In Java code, we add the label to the page with the same component identifier and the text Hello World, and voila, it renders Hello World. A more complex example, not too complex.
A link counter, a link that counts the number of times it's been pressed. So we create the text, we add some markup, so we have a link, we add a span
so we can update the text. We provide it with Wicket link identifier and the label with another identifier so that Wicket knows about them. In Java code, we create a page, a constructor.
We provide it with the number of times the link is clicked. We create a link that, when clicked, increases the count. We provide it with a label with the ID clicks and that binds its output to the clicks field
using a property model. The property model provides the data for the label. And we're done. Wicket is a nice framework for developers. There are two modes for running your application, development and deployment.
If you're running development mode, which is the default, you get this nice big red error message on standard error and you shouldn't deploy your applications using the development mode because development mode is particularly tuned for developers.
So you get nice error pages showing huge stack traces. You get dynamic markup reloading, so if you modify your markup, the markup gets reloaded into the final page. There's no caching enabled. The CSS and JavaScript are not optimized, so they're not minimized, they're not compressed.
It's tuned to discover programming mistakes early, like serialization errors or missing components. And finally, it shows the Wicket debugger quite prominently.
Conversely, if you run in deployment mode, which is used for production, we do our best to make the experience best for users of your application. So you have markup caching. We don't check everything. We don't display those huge stack traces to users.
Users don't like to see a null pointer exception. They just want to know there's an error, or rather, they'd rather not have the error. We minimize and compress JavaScript. We don't generate the Wicket tags in the markup. In development mode, those are visible, and the Wicket debugger is not visible.
A gratis tip. Don't perform your performance test using development mode. Once every six months, we get a message on our user list, someone saying, oh boy, Wicket does not perform. The first thing you ask, did you run it in development mode? Because of all the checks we do, it's slower than usual.
So a quick look at the Ajax debug window. So if you have the link counter page, at the bottom you see a link for debugger. If you click on it, you get a nice small window,
and that shows everything that happens with Ajax in Wicket. For example, you can see what components have been transmitted using Ajax. You can see the markup quite well. Our error messages are also very nice.
This is one I created. Unable to find a component with ID count in your home page. This means you declared the component in your markup, but that you did not add the component to your page, or the hierarchy does not match. Really nice message. And we tell you even where in the markup the offending stuff is.
Another thing that's really nice about Wicket is that you can test your pages. Anybody writing unit tests for their user interface? Not that many. Anybody writing unit tests at all?
Okay. So with WicketTester, a class we provide for Wicket, you can test your components directly. Or you can create a markup. You can run your tests without starting a server, so you can just run them in your JUnit runner.
You can test all the server-side interactions with Ajax. We don't start a browser, so you can't run JavaScript in a browser, but you can simulate a browser connecting with your page using Ajax. So it runs in your IDE using Ant or in your mason builds. And you can achieve quite high code coverage.
Committer for our project claims he has 100% code coverage for his application. But he's quite anal retentive. Testing examples are testing HelloWorld. So we create a test method. We create a WicketTester class.
We tell the tester to start with the HelloWorld page. And we assure that the text that's displayed contains HelloWorld. And boom, we have 100% code coverage for our HelloWorld page. The click count test. We create a method. We instantiate the tester.
We tell the tester to start with our counting page. We assert that the model value of our label is zero. Nobody has clicked on the link yet. And we click the link. And we assert that the model value is one. And there we have it. Again, 100% code coverage.
Well, WicketTester has some limitations. There are some extensions made for it. One by Ken Tong, page test. He is promoting it quite well. I haven't used it yet. Another framework that's quite well is JDave. It's a behavior driven framework where you can create the right specifications for your unit tests.
And also for your Wicket pages. Pretty awesome library. So, in summary, Wicket is widely used. It's component oriented.
It's a Java framework. And it's open source. Now, I wanted to tell you something about what's coming up in our next Wicket release. First of all, we have added some HTML5 support. It's not the best support there is.
But if you use a current Wicket version, our checks for valid markup don't work that nicely in combination with HTML5. Because HTML5 defines text, email, a number, a date, a search, and a URL field.
Those nice fields you get on your mobile device. Where you have a special keyboard for numbers or for an URL or for an email. And in Wicket, we check for programmer errors. And pre-HTML5, there was no email text field, and there was no search text field, and there was no URL text field.
So, anything different from hidden password or text, that was something that we said, well, okay, you made a mistake in your markup. So, that's not very nice. So, in Wicket 1.5, we provide text fields for those components.
And we're going to see how we can expand this using the validations that are available in the browser as well, and other stuff. But that's probably post-Wicket 1.5.
First we wanted to get the support out there, and then do our stuff. Then improve it. Wicket 1.5 has been quite long in development, but that was mostly because we tried to optimize our internals, or improve our internals. One of the things you'll note as a Maven user or an end user is that we split up the core library.
We just had one big JAR file called wicket.jar. And in the new world, we have wicket-request, util, and core. We split that up because we wanted to untangle the request processing.
The code was quite convoluted, everything could connect with anything. So we wanted to make it a nice, clean, separate bunch so it would be much easier to maintain. So if you're a Maven user, instead of depending on wicket, you should depend on wicket-core.
If you depend on wicket-extensions or wicket-spring, you'll get wicket-core automatically. So we simplified our request cycle. In Wicket 1.3, Wicket 1.5 decoding request handling was done in a state machine.
Anybody who debugged into the Wicket internals? One. Two. Okay. So you'll notice the steps part, and with a clause that if the number of steps you were circling was more than 10,000,
then you should throw an exception. Well, that's gone. So debugging was interesting. The pre-Wicket 1.5 request cycle was designed for flexibility. We didn't know what you wanted to do with Wicket or what were the possibilities, so we made it quite flexible.
Well, it served its purpose. After four years of running with Wicket, or five years developing Wicket applications, it took on some quite engineering. A lot of bug fixes that were augmented onto it, new functionality, so we made it quite new and improved.
So the request cycle processing in 1.5 is completely rewritten. Probably you don't notice anything about it, except if you're going to step into the code. The rendering code has been improved and simplified, and URL rendering has been completely rewritten and is also simplified.
So previously URL generation was scattered around our core framework. It's now in one place. One thing you might notice is if you have your own custom request cycle class,
it's still a possibility, but it's better to use our new feature. If you have a custom request cycle, you have to extend from a web request cycle.
And that became problematic with some add-ons, like if you have a hibernate request cycle that's similar to the open session in Vue filter. So at the start of the request you open a hibernate session, at the end of the request you throw your session away.
That collided with, if you wanted to have another, integrate with another framework that also created its own request cycle. Because in Java you can only extend from one superclass. So there's now a request cycle listener that provides the same events as the request cycle.
So you have the on-begin request, on-end request, and on-detach, and you can handle something with exceptions. So you can add them to the, configure them in your page, or in your application at the init.
So you add a new request cycle listener, a new iRequestCycleListener, etc. One of the major improvements in Wicket, and has been a feature request since I think 1.2, is to be able to publish events and subscribe to events without having, with an event bus.
So in 1.5 we now have a component event bus. We have an interface, iEventSource. Those are objects that can send events. And we have EventSync that can receive events.
The participants from Wicket framework perspective are components, the request cycle, the session, and the application. So let's take an event bus, let's take a look at an example. Again, the link counter page, but first we integrate it to Ajax functionality.
So here we have the Java code, where we left it. First, we tell Wicket to output a markup ID for our label. Otherwise, you can't update it using Ajax, using document.getElementByID.
And we place the markup. Next, we make the link an Ajax link, and it gets an Ajax envelope. And to the Ajax envelope, we add the count label.
This is currently in Wicket 1.4, the way to do Ajax. And if you wanted to make the link unaware of the other components it needs to update,
then you need to provide some code your own. So, pEventBus, it's not that nice that the link needs to know which component it needs to update. If you want to add another component to your page, and someone is not aware that the link should update it, that's hard.
It makes code brittle and harder to maintain. So a better way is to make the label refresh itself when an Ajax request passes by. And that's done with the event bus.
So here we have the counter again, we have the target add component, and we replace it with sendMessage to send the event to the bus. There are a couple of ways in how you can send events to the application,
or to all components, etc. That's done with the broadcast parameter. And next we need to create a component that is aware of these events. So we create a countLabel class that extends label against constructor,
and sets its output markup ID. And in the onEvent method, we do our logic. So if the event's payload is something the link of the label is interested in,
in this case an Ajax request target, we add ourselves to the Ajax request target. So now that we have an event bus, we can see it's a bit more code.
You need to create your own class, your components need to become aware of the event bus. Updating components is now completely decoupled. So the components that want to update themselves in the markup
are decoupled from the components that received the events. One of the things you can do is make the event that you publish more type-safe. So instead of an Ajax request target as the payload, you can create a count event,
so that only the components that are interested in the count event get re-rendered. And finally, Ajax requests automatically create a default event with the Ajax request target as payload. So in this example, I didn't need to publish the Ajax event.
And this is just the surface of the stuff that has been changed in Apache Wicket 1.5. There's a complete migration document where we publish all the APIs that have been changed,
all the deprecations that have been removed, and lots of other stuff that has changed. So I wanted to ask if there are questions for me.
It's really early. I don't bite. What's the threading model behind the event bus? Are these events distributed synchronously, or is there a queueing mechanism? What does it work? The question is, is there a threading model behind the event bus?
The event bus is, if you have a request going into Apache Wicket, for one user, for one request, there can only be one request happening for a particular page. So you have a single-threaded programming model for Wicket.
Your components don't need to be aware that there are many threads running, unless you're doing things like keeping a session in a static field, like a co-worker of mine did. So you have a single-threaded programming model. And the event bus just builds on that, so there is no thread dispatching mechanism for the threads.
Any other questions? I have a chance to put an error to compile errors. If the ID doesn't fit, I see it at run time, not at compile time.
The question is, is it possible if you make a mistake in your markup, the error page I showed earlier with the message that you forgot to add a component to your page, and if you can make that compile time, so you can run your Maven build or your compiler warnings,
your compiler gives you error messages that you forgot something. It's quite difficult to achieve that, because the Wicket component model is very dynamic. You can add and replace components at will. That said, I remember that in NetBeans and in IntelliJ there are plugins available,
and they give red squirrely lines if it's not available in either the markup or in the page. So there is some IDE support, but not for Eclipse.
And there are people who have... There is some discussion on the user list about such a plugin for Maven, or that tries to do something similar like that. Basically what I do is just try to create a unit test for every page in my application
that just instantiates the page and fills the unit test. Any other questions? I was wondering how this is combined, because with Wickets you control the page flow and dynamics from the server
by getting all the click events, whereas in jQuery applications you control FC from within the browser. In the beginning I said that there was a YQuery project for integrating Wicket with jQuery.
The question is, how does that work?
How can you integrate jQuery, which is a JavaScript client-side library, with Wicket? Most of the time, at least in my experience, is that you want to leverage all the jQuery widgets that are available, a date picker or a nice panel that opens and closes, accordions, etc.
And most of the stuff happens at the client-side, and the server does not need to be involved in it, so what we typically do is just generate all the components you need for your widget. For instance, for your accordion, you have five panels, you generate the five panels in your markup,
and you attach the accordion YQuery behavior to that panel, or to that list of panels. And that does its magic, so it's very easy to add JQuery behavior to your Wicket components using YQuery.
It's just a couple of lines of code. And some events use the Wicket event bus to communicate, but there's no separate bus for JQuery events to Wicket.
Is that enough? Okay. It's quite well documented, and the code is very, very readable. They also use the very nice feature of Java. You can use the dollar sign as an identifier, similar to JavaScript,
so they've used the dollar identifier for using YQuery components. Any other questions? I see a hand rising, but that's not... Okay, well then, I think that's a wrap.
Thank you.