Wicket, the big door for Java developers

[Hussein Baghdadi]

Man, I started to fall in love of Wicket !
It is appear that Wicket benefited well from Tapestry.
Things I like in Wicket :
The use of XHTML namespaces in Wicket (smart choice).
Integerated AJAX support.
Adding components mechanism.
No configuration XML files, neither annotations -AFAIK-.
But one drawback -I think- is you hard-code component's name in your Java code :
add(new Label("message", "Hello World!"));
What if you want to change component's name ?
(Maybe we well use properties file, or XML file again )
Also I notes Wicket pages are not testable, like their cousion, Tapestry , due the extending of abstract class (please correct me if I'm wrong).
I will sit and watch carefully what happen in Wicket space and learn it onces it become a mature framework (Wicket 2 , maybe ?)
Well, this is my peaking review about Wicket, what about yours ?

[Karthik Guru]

No configuration XML files,

Yes

neither annotations -AFAIK-.


Annotations for injecting Spring beans and can use annotations for authorization/authentication...IAuthorizationStrategy is really nice. (Not a must in both cases. But they look nice.) Check it out when you find time.


add(new Label("message", "Hello World!"));
What if you want to change component's name ?
(Maybe we well use properties file, or XML file again )


I think never ..'No XML' - is one of their claims to fame
Either way, wicket identifies the component through the value assigned to "wicket:id" attribute and not element 'name' as you mention.
Why w'd you want to change wicket:id attribute value ?


Also I notes Wicket pages are not testable, like their cousion, Tapestry , due the extending of abstract class (please correct me if I'm wrong).


No that is a misconception. WicketTester, FormTester, WicketTesteHelper classes can be used to test your pages *outside* the container. Please check the javadocs for more information. Wicket ships with number of unit tests.


I will sit and watch carefully what happen in Wicket space and learn it onces it become a mature framework (Wicket 2 , maybe ?)


IMHO it already is (mature). wicket 1.2 is a *major* release with tons of nice features. Its currently beta3. But final should be out very shortly.
Yes with wicket 2, wicket will embrace java5 completely.
But there will be a small intermediate release - 1.3 which will be significant. But I would suggest that you start experimenting with 1.2 right away.

[Hussein Baghdadi]

Well, check this :
<span wicket:id="message">Message goes here</span>
message is hard coded in Java code, what if you want to change it ?

[Martijn Dashorst]

Originally posted by John Todd:
Well, check this :
<span wicket:id="message">Message goes here</span>
message is hard coded in Java code, what if you want to change it ?

But why would you want to change it? It is the identifier for the component. It has no external use, a web designer can't do anything with it, other than screw its value up ;-)

Seriously. The wicket:id is something you never or almost never change. And if you do, then you also need to do so in the Java code.

To alleviate this, you'd need a level of indirection, which would mean another place to configure it (now the definition is in three places, giving 2 places to mess it up). Another way would be to completely generate the markup from the Java side, but then you'll end up with Echo(2).

I think Wicket is in the sweet spot here. I haven't had the need to somehow change the value of the wicket:id, and not change the Java code with it. There simply is no need for it. The other way round is more worrisome: when you use CompoundPropertyModels, then your component's ID also acts as an OGNL expression, and you have to maintain those paths when you change the name of a property in that path.

With the upcoming IDE support, this will become even better supported and your IDE will give warnings/errors when components can't be matched.

[Hussein Baghdadi]

Aaaa, I don't mean wicket:id , I mean message.
You hard-code the component name in your code then you refer to it in you HTML page.

[Hussein Baghdadi]

Any way, What about integerating Spring with Wicket ?
How Wicket use "freindly URLs" since there are no configuration files ?
What about integerating with JEE security ?
It seems hard to me how to use these stuffs with Wicket without config files !
Ah, annotations, maybe ?
Even annotations are not that -great solution- , you hard-code your config infos in your code.
You have to compile your code if you changed your annotations.
Please correct me if I'm wrong.
[ April 13, 2006: Message edited by: John Todd ]

[Martijn Dashorst]

Originally posted by John Todd:
Any way, What about integerating Spring with Wicket ?

What do you want to integrate with Spring? Auto-inject your DAO's into your pages?

How Wicket use "freindly URLs" since there are no configuration files ?

Read the excellent article on Javalobby regarding URL mounting.

What about integerating with JEE security ?[/QOUTE]
What about it? Wicket's first class component model allows you to build per-component authorization. Wicket supplies an example role-based implementation for authentication and authorization using annotations. And yes, that requires configuration in the form of annotations.

At Topicus (my company) we have implemented our own JAAS enabled framework on top of the Wicket authorization and authentication interfaces. It allows a granularity of defining access to components and data in a way I haven't seen in other frameworks yet. This JAAS framework is not part of the Wicket distribution.

It seems hard to me how to use these stuffs with Wicket without config files !

Wicket isn't a replacement for other frameworks such as Hibernate, Spring, or log4j. Wicket doesn't need configuration files for itself, but that doesn't mean the other frameworks can live without them.

Why the focus on configuration files? Sure, Wicket doesn't need external configuration files for itself, but that isn't the strongest point of Wicket. It is the first thing new users notice, for sure. But Wicket isn't just about 'zero-configuration'. I have worked with Wicket for over a year now in commercial programming, and I don't notice the lack of configuration.

The way you build web applications using Wicket is its strong point. You get clean code, good separation of concerns and a superior component model, unlike anything out there.

[Hussein Baghdadi]

What do you want to integrate with Spring? Auto-inject your DAO's into your pages?

Well, Yes and ofcourse using Spring AOP.

Wicket doesn't need configuration files for itself, but that doesn't mean the other frameworks can live without them.

Yes, I know but it seems hard to me how to make Wicket works since there are no configuration files.
So, you have been working with Wicket for over a year, How did you found Wicket ?
Is it powerfull enough ? Is it easy to learn ? Have you tried Tapestry ?

[Chris Mathews]

For those that don't know Martijn Dashorst is one of the driving forces behind the Wicket Project. If you ever had questions about Wicket and how to effectively use it... this is your guy!

[Gregg Bolinger]

Yes, I know but it seems hard to me how to make Wicket works since there are no configuration files.

Wicket is a Java programmers web framework. Everything you do, except the HTML templates, is in Java code.

One thing I often think of when looking at configuration files is this...How often do you really change something in a configuration file and not have to redeploy your web app? Especially during development. For me, it's never. So then one might argue that you can deploy without rebuilding. Well, I suppose that's true, but I use Ant. So the whole process is just a simple ant command.

For those that don't know Martijn Dashorst is one of the driving forces behind the Wicket Project. If you ever had questions about Wicket and how to effectively use it... this is your guy!

Martijn truly is the man when it comes to Wicket. If we all start using and asking more questions, maybe he'll want to stick around more.

[Karthik Guru]

Well, Yes and ofcourse using Spring AOP


Yes you can inject springified objects by just annotating your field using wicket's @SpringBean annotations.

So you can have something like this ..

class YourPage extends WebPage{
@SpringBean
private PersonDAO personDao;
YourPage(){
List persons = personDao.getAllPersons();
}
}

where PersonDao is declared in the spring config file. Wicket will resolve the 'personDao' spring dependency when YourPage initializes. Does this qualify as transparent Spring integration for you?


Yes, I know but it seems hard to me how to make Wicket works since there are no configuration files.


Why do you think its hard to make a framework w/o config files. Config files in general introduce another level of indirection. If there are intelligent defaults, you don't need any kind of mapping information and hence no config files are required. Wicket maintains information in the java page class itself. As Martijn already pointed out, wicket doesn't have config files of its own but that doesn't mean that you can't have a Spring-Config file for example to integrate with spring.

[Hussein Baghdadi]

And I'm asking him if he find Wicket powerful since he is working with it more than year ? (Damn, I'm really silly )

[Karthik Guru]

Is it easy to learn ?

IMHO, yes once you get a good grasp of Wicket models
It's similar to jsf's backing beans etc. And no worries if you have a little trouble initially. Drop by at the wicket mailing list. It has great support with great set of core-developers. If you want a functionality added to the core and if you can convince them then there is every chance that it will make it to the head the same day!. Wicket has stateful components and that makes it so easy to work with.

[Martijn Dashorst]

Originally posted by Gregg Bolinger:
One thing I often think of when looking at configuration files is this...How often do you really change something in a configuration file and not have to redeploy your web app? Especially during development. For me, it's never. So then one might argue that you can deploy without rebuilding. Well, I suppose that's true, but I use Ant. So the whole process is just a simple ant command.

I typically only have to redeploy when the hotspot compiler can't swap out my code, so when working with Wicket in pure development mode:

the application starts in development mode

the application runs in the debugger of Eclipse

I usually don't have to redeploy my webapplication, and no Ant or Maven comes into play. The only circumstances Eclipse gives me a hard time is when I change something the classloader already has committed into mem, and only when signatures change (inheritance, method signature, return type, etc).

I can change the implementation of methods without having to redeploy, I can change the markup of a page without having to redeploy, I can even add new components to a page without having to redeploy, as long as it doesn't involve subclassing.

This workflow makes it very efficient creating web applications.

The lesson here: only when you don't have configuration files, and your framework fully supports that model, you will see the benefits. And when you don't have to use configuration files, you even forget there's a whole world out there updating them

For those that don't know Martijn Dashorst is one of the driving forces behind the Wicket Project. If you ever had questions about Wicket and how to effectively use it... this is your guy!

Martijn truly is the man when it comes to Wicket. If we all start using and asking more questions, maybe he'll want to stick around more.

blush

[Martijn Dashorst]

Originally posted by John Todd:
And I'm asking him if he find Wicket powerful since he is working with it more than year ? (Damn, I'm really silly )

I have done work with maverick + baritus (open source binding framework for maverick), and I never got the hang of struts. I must say I never want to look back at those applications

At my previous employer we used to build rich client (win32) applications using C++Builder, and that was pretty sweet. It was very hard for me to work with Maverick and model2 frameworks coming from that perspective. With Wicket, the model concept was pretty hard to understand, and even now I'm constantly amazed what you can do with them.

To read more about my experience with Wicket, read this article I wrote for JavaPolis' JavaNews.

[Frank Silbermann]

When programming in Wicket you would put the same kinds of things in configuration files that you would if building desktop applications or fat clients with Swing -- namely, problem-oriented information to be provided by the deployer. Since the tool has know way of knowing the options the developer wishes to give his application's deployers, configuration files are used only if the developer designs his application to use them.

You can build Swing, AWT and SWT based applications without using configuration files, so instead of asking how Wicket gets along without them you should be questioning why so many web frameworks need them. Most web frameworks are still based on the idea of hacking into a web-server's delivery of static HTML pages to inject a degree of dynamic interactivity. Since HTML pages are not programming language constructs, a tool is required to assemble and organize them, and typically the tool's interface is based on XML.

Wicket programmers, in contrast, do not think in terms of hacking into a web-page server's mechanism. Though the Wicket framework itself is implemented as a Java servlet, Wicket is best thought of as a framework for building GUI-based client-server Java applications. To ride on top of the web, Wicket uses HTTP as the client-server networking protocol, and its GUI toolkit provides customizable components whose rendering is defined and implemented via bits of HTML.

Though Wicket's implementation uses some ideas taken from Tapestry, the only framework I know of which might have a similar style of programming is Echo. I don't know Echo, but my impression is that Echo completely hides the HTML from the developer, whereas Wicket programmers write simple bits of HTML to configure the display of its GUI components (and any subclasses of them the user chooses to define).

If writing client-server programs using an object-oriented language is more appealing to you than coding and configuring tag-files, then you'll probably like Wicket. You'll want to use it on those occasions when you have no choice but to use HTTP as your networking protocol and must execute your client program inside a web browser (which seem to be frequent requirements these days).
[ April 18, 2006: Message edited by: Frank Silbermann ]

[Karthik Guru]

Though Wicket's implementation uses some ideas taken from Tapestry, the only framework I know of which might have a similar style of programming is Echo.

Does tapestry support stateful components and pages like wicket? If it doesn't then the only similarities are that they have swing-like components and work out plain html templates? How about echo? Is there any other framework that manages state/session like wicket?

[Gregg Bolinger]

There is also wingS which I would put in closer comparison to Echo that Wicket.

[Hussein Baghdadi]

Hi again.
Check this guys (Annotations vs config files).
http://www-128.ibm.com/developerworks/java/library/j-cwt08025.html

[Jonathan Locke]

Originally posted by Frank Silbermann:

Though Wicket's implementation uses some ideas taken from Tapestry, the only framework I know of which might have a similar style of programming is Echo.

Just to set the record straight, I only took one very general idea from Tapestry when I created the alpha version of Wicket: using an attribute to associate behavior implemented in Java with markup. Any other similarity to Tapestry is complete and total coincidence because I started absolutely from scratch with Wicket (to be honest, I wouldn't know how to copy Tapestry because after reading the book twice I still didn't understand it very well). The one apparent similarity to Tapestry users is probably the name 'RequestCycle'. However, that is a misconception. I actually did not start out with a RequestCycle at all, but gradually discovered there was a need for it... I picked the name RequestCycle reluctantly and simply because there is no better name for what it represents (and believe me, I thought about it for a long time!). As far as Echo goes, I heard that it generated HTML and didn't support the back button... so I never even downloaded it. Echo simply doesn't meet any of my requirements for a web framework, so it had no influence on Wicket at all.

[Jonathan Locke]

Originally posted by John Todd:
Aaaa, I don't mean wicket:id , I mean message.
You hard-code the component name in your code then you refer to it in you HTML page.

Right. This is the only way I can think of to associate code with markup. To say it's "hard-coded" is a bit of a stretch. It's an identifier like any other identifier. Heck, your variables have names, don't they? They're just enforced by the compiler. "Hard-coding" usually refers to CONSTANTS that ought to be externally configurable or at least logically named, like language strings that require localization. That sort of thing is a major pain because localizing the application requires that you "soft-code" all the strings by loading them from a file or other location using, yep, /a constant id/.

I think the valid criticism you meant to bring up is that there isn't IDE support for making sure that the ids match up with the code (we do, of course check that they match up at runtime). However, this is soon going to be a misconception because Geertjan Wielenga (sp?) at Sun is working on a plugin for NetBeans for JavaOne in June which will take care of all this for you! I expect Eclipse support won't be far behind as Wicket really starts to take off this Summer and Fall.

[ April 22, 2006: Message edited by: Jonathan Locke ]
[ April 22, 2006: Message edited by: Jonathan Locke ]

[Jonathan Locke]

A few thoughts and observations about some of the questions asked in this thread:

- I've been using wicket since day 1 (since I designed it) and I'm not being conceited in saying that it's vastly more productive for me than any other web framework. The simple reason is that getting back to Java itself is more productive for me.

- I know nothing about Spring or Spring integration. I love that Wicket supports Spring and someday I may use that, but you don't actually need Spring. You can use any of several Hibernate integration projects, including my own little such project in wicket-stuff.

- Friendly URLs are achieved in Wicket by "mounting" pages or whole packages of pages on various URLs. This is done through ordinary method invocations like pretty much everything else in Wicket.

- There's really no need to integrate with JEE security. Actually, you can write pretty complete web applications without any container-provided feature in Wicket. Wicket's built-in security mechanism is decoupled from URLs and is more OO, component-oriented, powerful and granular than JEE security. I think once you understand it (which should not take long), you will never want to use JEE security again. Not only can you deny access to pages, you can even do something like: don't show this panel unless the user has the admin role. It's extremely easy to do this with annotations or Java. If you really want to externalize it into XML, you can do that easily on your own. You can also write your own authentication or authorization implementation. It's all completely pluggable.

- I think Wicket is actually easier to configure because our configuration is supported, documented and checked by your IDE. If you have an actual NEED to externally configure your settings, you can simply use our API to set values you read from XML... or use something like beanshell to script the whole thing. Personally, I don't find scripting the config calls at all useful on the projects I work on (I just use Jetty, which restarts in no time, and direct config in Java) so I don't do it. But you can do it easily enough if you want to. We do support "modes" (deployment, development, etc) and you can change that in your web.xml, I believe. This seems to be more than good enough for me. If someone really wants to make a module for external config of Wicket settings, we'd certainly take that contribution in wicket-stuff, but I don't view that problem as part of the core. The Wicket core is pretty much entirely a Java API.

[Jonathan Locke]

Originally posted by Karthik Guru:

Does tapestry support stateful components and pages like wicket? If it doesn't then the only similarities are that they have swing-like components and work out plain html templates? How about echo? Is there any other framework that manages state/session like wicket?

I don't pretend to understand much about Tapestry, but to my knowledge, Tapestry components are not transparently stateful in the way that Wicket components are. In my own brain, I don't think of Tapestry as truly OO in the way that Wicket is... as in normal Java objects with normal state. If you look back to the Tapestry mailing lists around April 2004, you'll find me asking lots of annoying questions about Tapestry's state management on there. After pissing Howard off, I finally decided that Tapestry had taken the wrong approach to the whole problem. So I think you are correct if you think that Wicket's state management is its biggest differentiator from Tapestry. It's unfortunately one of the last things that people notice when glancing at the two frameworks! That dawns on them later. Ooooh. It's just Java. YEAH. That's kindof the whole point.

[Jonathan Locke]

Originally posted by John Todd:
But one drawback -I think- is you hard-code component's name in your Java code :
add(new Label("message", "Hello World!"));
What if you want to change component's name ?
?

The question isn't quite right. You meant 'what if I want to change the components /id/'. The only reason I can imagine wanting to do that is simply to make the id you chose more meaningful to readers of your code. In that case, it's simple refactoring. You change the id in the HTML and the Java so they match up again. A designer would never change it.

But I just realized that you may not know that wicket ids are scoped. They do not have to be globally unique! You can use the id 'message' elsewhere on the same page even. You just can't use it twice /in the same container/. Also, wicket:ids have no other purpose than identifying the Java component that's connected to the tag.

[Hussein Baghdadi]

Cool, we got another Wicket expert at the ranch (Hello Jonathan Locke).
Well, fogive me for being ill-informed, it is just my peeking review

but you don't actually need Spring

But Spring is a very important addition to our life (at least to me), it is not just about integeration Hibernate with Wicket.
For me, it is about Spring AOP, good exceptions framework, abstractation layers and many other things that make Spring a silver bullet.

I love that Wicket supports Spring and someday

Personally, I would like to see it very soon...
What are the applications that Wicket fits well ?
Is it suitable for high concurrent applications ?
Is it framework for mid-sized application or for large-sized ?
Why Wicket's API naming schema is -somehow- wierd (in Java, we told to use the domain name).
You know, com.wicket.ajax ....
Would you mind asking you to write some tutorials and tips about Wicket in JavaRanch journal (or even in this forum) ?
I really like Tapestry and Wicket frameworks, the use of HTML templates and Java code is simply killer (for JSF guys, Shale will use this approach, but again as a special attribute jsfid, not as the elegant solution of Wicket).
Thanks Jonathon

[Igor Vaynberg]

Originally posted by John Todd:

What are the applications that Wicket fits well ?
Is it suitable for high concurrent applications ?
Is it framework for mid-sized application or for large-sized ?

Wicket is suitable for any kind of application. Where it really shines are application with complex UIs.

The scalability question always comes up, and it is very difficult to answer because there are just too many variables. Wicket is pretty heavy on session state, more so then other frameworks I believe, so by default it will not scale as well as a stateless application. That said, there are numerous ways built into the framework for you to optimize/reduce session state. The advantage is that you dont have to do this as your are building your app. You can build it, test it, and then only invest time to optimize the hotspots, instead of wasting a lot of time trying to figure all this out upfront.

Originally posted by John Todd:


Why Wicket's API naming schema is -somehow- wierd (in Java, we told to use the domain name).
You know, com.wicket.ajax ....

Is it really weird? You will not clash with the namespace so you are ok.

[Karthik Guru]

Originally posted by John Todd:
Cool, we got another Wicket expert at the ranch (Hello Jonathan Locke).

Now we got one more in Igor.

[Martijn Dashorst]

Hi John,

Quite a few questions...

Originally posted by John Todd:
Cool, we got another Wicket expert at the ranch (Hello Jonathan Locke).
What are the applications that Wicket fits well ?

I guess I would categorize them as (highly) interactive, complex gui applications that need to run in a browser. Our company is typically building administrative applications, and Wicket is a solid choice there.
I think that for highly multi media applications I would try to see if something else might work. However I know that that is possible to with Wicket.

Is it suitable for high concurrent applications ?

We have done our best to make sure it is performant and scalable. I know of one company that has created a highly scalable portal solution using Wicket. I am not at liberty to disclose the company, but their application and company is reportedly worth $10 million dollars.
Wicket is currently highly dependend on the session, but you can tweak that behavior to the fullest. I have monitored our session sizes for our major application and I didn't see a problem (yet). The session size is not larger than for any other typical application of the same or less complexity.

Is it framework for mid-sized application or for large-sized ?

Depending on your value for mid-sized and large-sized. I think the better question is, is your team accustomed to developing object oriented software. If they truly understand object orientation, I think you can scale development considerably.
In my opinion (but I'm biased) Wicket is suitable for both types of projects, but that it depends on the experience of your team. If you have a century of struts experience in your team, then I'd suggest to use struts. In such an environment, I'd start with smaller projects to get used to the wrinkles of a new framework. But this is more of a general advice on general software engineering.
Technologically there is no limit to the size of the application. Only server memory :-). In a recent thread on JavaLobby (quite heated), some harsh comments are made concerning Wicket's scalability, but I have yet to see the calculations that Wicket won't scale. Those discussions are always done on gut feelings, instead of requirements and actual calculations.

Currently one of Wicket's most major problems is that it is used mostly for internal applications within the corporate network. As far as I know there are no public, high traffic websites running Wicket. I know there are several in the pipeline, but they still have to launch.

Why Wicket's API naming schema is -somehow- wierd (in Java, we told to use the domain name).
You know, com.wicket.ajax ....

It is more of a convention than an actual law :-). The convention says that your framework/company should 'own' the domain that is in the packages.

Being a volunteer effort, Wicket has moved around quite a bit. First Jonathan developed it in his own company, and everything was named 'com.voicetribe'. After that, Wicket moved to codehaus, which would have required 'org.codehaus.wicket'. Next we couldn't get access for new developers at codehaus, so we moved the project to sourceforge, making the next rename 'net.sf.wicket' or 'net.sourceforge.wicket'. There has been quite some talk about moving again, after the service of sourceforge degraded considerably. So that is why we opted for a top level name, just as junit did.

I hope this is enough information to digest
[ April 24, 2006: Message edited by: Martijn Dashorst ]

[Edward Durai]

Hi,

I am using spring, wicket and hibernate with annotations. i have one doubt, In wicket each page contains
1. .java file
2. .html file (using wicket:id="name mentioned in java")
3. property file
I hope I am correct

I have a one doubt.

I Want to dynamically display the label name and its field(text/combobox/textarea or other)

Example :
I have a xml file like
<DYNAMIC>
<FIELDS LABELNAME="USERNAME" FIELDTYPE="TEXT"/>
<FIELDS LABELNAME="PASSWORD" FIELDTYPE="TEXT"/>
<FIELDS LABELNAME="COUNTRY" FIELDTYPE="COMBO"/>
</DYNAMIC>

I WANT TO DISPLAY DISPLAY LIKE BELOW
Expected result is:

USERNAME TEXTBOX DISPLAY
PASSWORD TEXTBOX DISPLAY
COUNTRY COMBOBOX DISPLAY


Is it possible to create these dynamic controls(label name and fields)
using WICKET?

If it is yes, how to get the dynamic inputs to other java file?

Kindly reply this.

Thanks for replying.

[ November 09, 2006: Message edited by: Edward Durai ]
[ November 09, 2006: Message edited by: Edward Durai ]