• Post Reply Bookmark Topic Watch Topic
  • New Topic

Wicket - next big thing?  RSS feed

 
Vinnie Jenks
Ranch Hand
Posts: 207
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is anyone using Wicket successfully yet (in anything other than small, trivial applications?)

http://wicket.sourceforge.net/Features.html

I've walked through a couple of the tutorials and read some of the 3rd. party articles...and I'm very excited about this!

This looks like a superior alternative to other MVC frameworks like Struts, WebWork, JSF, etc. It appears to have all of the ease of ASP.NET (e.g. no xml config files to manage) and uses standard HTML.

I'm anxious to hear some real-world feedback!

Thanks!
 
Jonathan Cone
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not currently using this, but now that I see what it is I might just start. It really looks like everything I've been looking for.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wicket is nice, but immature. You might want to take a look at Tapestry if you like the looks of Wicket.
 
Vinnie Jenks
Ranch Hand
Posts: 207
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By immature, is that to say that it is not stable enough? Fast enough? Not enough "community support"?

From what I've heard it's catching on very quickly and is already quite popular.

The advantage over Tapestry, Struts, etc. is that you get all of the functionality w/o all of the cumbersome XML configuration files.

I'm going to do some testing and see what I can se...it looks great to me!
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vinnie Jenks:
The advantage over Tapestry, Struts, etc. is that you get all of the functionality w/o all of the cumbersome XML configuration files.


Calling that an advantage is an opinion. However, the same thing can be achieved in Tapestry using Annotations.
 
Francis Amanfo
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:


Calling that an advantage is an opinion. However, the same thing can be achieved in Tapestry using Annotations.


Gregg,

That the same thing can be achieved in Tapestry with annotations is not entirely true. Because even if you move all your components into the template via implicit components and annotations in your page class you still need page specifications with the empty <page-specification></page-specification>. In Wicket there is no such thing. The only configuation file is the web.xml, which all Java web applications can't just do without.

My .02 cents.

/F
 
Francis Amanfo
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vinnie Jenks:
Is anyone using Wicket successfully yet (in anything other than small, trivial applications?)

http://wicket.sourceforge.net/Features.html

I've walked through a couple of the tutorials and read some of the 3rd. party articles...and I'm very excited about this!

This looks like a superior alternative to other MVC frameworks like Struts, WebWork, JSF, etc. It appears to have all of the ease of ASP.NET (e.g. no xml config files to manage) and uses standard HTML.

I'm anxious to hear some real-world feedback!

Thanks!


Hi Vinnie,

I've developed applications both with Wicket and Tapestry. My last Wicket application can be found here http://www.ibfd.org. Especially this part of the application is more interesting: http://www.ibfd.org/portal/app?bookmarkablePage=org.ibfd.portal.presentation.Shop
The front end is 100% Wicket.
My experience? I think you achieve difficult things more quickly with Wicket than Tapestry, but must emphasize though that I have no experience yet with Tapestry 4.0 which folks claim is a great improvement over it's predecessors.

Francis
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Francis Amanfo:


Gregg,

That the same thing can be achieved in Tapestry with annotations is not entirely true. Because even if you move all your components into the template via implicit components and annotations in your page class you still need page specifications with the empty <page-specification></page-specification>. In Wicket there is no such thing. The only configuation file is the web.xml, which all Java web applications can't just do without.

My .02 cents.

/F


Not true. Ok, there are 2 configuration files for Tapestry if you do not use .page files. There is the web.xml and the [appname].application file. If you use annotations you don't need .page files at all. But in your .application file, you have to tell it where to get all your classes that extend BasePage (or your version of BasePage) using

<meta key="org.apache.tapestry.page-class-packages" value="your.package.pages"/>

I'm not saying Tapestry is superior to Wicket. I just prefer Tapestry and it's been around longer than Wicket. The mailing list for Tapestry is very active and very helpful. I've used both and I can get more done with Tapestry quicker. But that is just me.
 
Michael Duffy
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vinnie Jenks:
By immature, is that to say that it is not stable enough? Fast enough? Not enough "community support"?

From what I've heard it's catching on very quickly and is already quite popular.

The advantage over Tapestry, Struts, etc. is that you get all of the functionality w/o all of the cumbersome XML configuration files.

I'm going to do some testing and see what I can se...it looks great to me!


You've got to put configuration somewhere. The whole point of XML configuration is to move it outside the source code. Annotations seem to put them back in the source code.

There's no free lunch. For all those folks who complain about XML configuration 9e.g., Spring app context XML) I'd ask: What's the alternative? Hardwiring dependencies in code seems more brittle to me.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Duffy:


You've got to put configuration somewhere. The whole point of XML configuration is to move it outside the source code. Annotations seem to put them back in the source code.

There's no free lunch. For all those folks who complain about XML configuration 9e.g., Spring app context XML) I'd ask: What's the alternative? Hardwiring dependencies in code seems more brittle to me.


And this is why we have options like Wicket, Tapestry, Struts, JSF, Spring...

We don't have to decide which one is best. We have to decide which one is best for me or you or more importantly, the current project.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I will say this though in defense of the less XML is better philosophy (not necessarily no XML)...When using annotations in tapestry and when things aren't working, not having to bounce back and forth between my .page file and my java class is a huge plus to me.
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vinnie Jenks:

The advantage over Tapestry, Struts, etc. is that you get all of the functionality w/o all of the cumbersome XML configuration files.


Yes there is no XML but the component tree hierarchy has to be assembled explicitly on the server side unlike tapestry. For some that might be cumbersome /more code too? I dont know.
 
Frank Silbermann
Ranch Hand
Posts: 1408
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Duffy:
You've got to put configuration somewhere. The whole point of XML configuration is to move it outside the source code. Annotations seem to put them back in the source code.

There's no free lunch. For all those folks who complain about XML configuration 9e.g., Spring app context XML) I'd ask: What's the alternative? Hardwiring dependencies in code seems more brittle to me.
There are no XML annotation files needed when building Swing fat-client applications.

My belief is that any decision to be made by deployers should be put in configuration files; any decision made by programmers should be put in code.

Many J2EE web frameworks use configuration files to encode decisions made by programmers because they are perversely oriented around tag-based mark-up files rather than Java objects. Wicket returns the emphasis to where it belongs.
[ January 17, 2006: Message edited by: Frank Silbermann ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Duffy:

There's no free lunch. For all those folks who complain about XML configuration 9e.g., Spring app context XML) I'd ask: What's the alternative?


I'm really not an expert on these things -- more a student of Web frameworks than anything else, so don't flame me if I'm telling you all things that you already know. But the Ruby on Rails philosophy, which Wicket seems to be picking up on, is that conventions are an alternative to any kind of configuration. If an app is, by convention, set up a certain way, then there's no need to configure that setup. Rails does some very interesting things: given a model class in a certain directory, Rails automatically can find the View you intend for it to use, the database tables to persist the Model in, dedicated helper classes, etc, all just using naming conventions. There's almost no configuration for a basic Rails app: tell it what database adapter to use, and that's often enough.

It's interesting that Sun's own Java standards apply this philosphy in some areas (the JavaBeans conventions, for example) but not in others (webapp layout.) The J2EE web app design gives absolutely no guidance at all -- you can do anything you want, the sky's the limit. The result, though, is all the configuration you have to do. Too much freedom can be a bad thing.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's interesting EFH. What I would be curious about is, when using Rails, you need to do something a bit out-of-the-box so to speak. How difficult is it to make Rails to something different? I guess the real questions is why are you doing something different if the framework conforms to how webapps should be written. But we all know in the real world there are things you just can't account for.
 
Michael Duffy
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:


I'm really not an expert on these things -- more a student of Web frameworks than anything else, so don't flame me if I'm telling you all things that you already know. But the Ruby on Rails philosophy, which Wicket seems to be picking up on, is that conventions are an alternative to any kind of configuration. If an app is, by convention, set up a certain way, then there's no need to configure that setup. Rails does some very interesting things: given a model class in a certain directory, Rails automatically can find the View you intend for it to use, the database tables to persist the Model in, dedicated helper classes, etc, all just using naming conventions. There's almost no configuration for a basic Rails app: tell it what database adapter to use, and that's often enough.

It's interesting that Sun's own Java standards apply this philosphy in some areas (the JavaBeans conventions, for example) but not in others (webapp layout.) The J2EE web app design gives absolutely no guidance at all -- you can do anything you want, the sky's the limit. The result, though, is all the configuration you have to do. Too much freedom can be a bad thing.


You can put your asbestos underpants away, Ernest. 8) No flames here.

I've yet to pick up Ruby or Rails, but it's on my todo list for this year. I've heard that Ruby on Rails makes things "easy", and I'd like to find out for myself what that means.

It's one of the questions I wrestle with about Java and JEE: Why is it so hard? It seems to me that it's been developed with the enterprise in mind. But a significant percentage of applications that clients want just mean connecting to a relational data source and exposing the information for CRUD operations. As I understand it, the beauty of .NET and Rails is that they make this "easy". I don't believe there's anything fundamental about Java/JEE that makes it inherently harder, except for a lack of tools.

I'm not sure if the new Trails initiative helps this situation. I haven't tried NetBeans for UI stuff, since I'm firmly in the IntelliJ camp.

I like the quote from Alan Perlis: "A language that doesn't affect the way you think about programming, is not worth knowing". I'm hoping that learning Ruby will affect the way I think about programming in general and JEE in particular.

Thanks for the fine discussion.
 
Martijn Dashorst
author
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:
Wicket is nice, but immature. You might want to take a look at Tapestry if you like the looks of Wicket.


According to your own saying, you are not familiar with Wicket. How can you possibly be so bold and claim such nonsense.

Wicket may not be as old as Tapestry, but it most certainly is mature to be used in production systems. Furthermore, you claim that the Tapestry community is more friendly and speedy, however you have not joined our community to be able to judge that. I'd prefer that you keep from making bold statements about a product until you have done some basic research at the very least.

I think that Tapestry is a great product and that both Wicket and Tapestry have a place. Many people like working with Tapestry and I won't deny that. However, there have been several developers who tried working with Tapestry who had a hard time building applications with it. Some of them joined our community and are happy Wicket users. Perhaps the same thing has happened with Wicket users moving to Tapestry, but I can't recall any of them.

To answer the original question on who is using Wicket in the real world, I know of two large three large applications that are currently developed. TeachScape, which is an online learning environment with 65000+ members, Topicus (my company) is building a school administration system which will be required to host 20000 users or so, and one I don't know the company of, but they are already at 300+ pages in development and due to go live within two or three months.

There is another project, which will also host about 1000 users. I don't know if I'm allowed to disclose which company and what product they'll be building. Perhaps they will disclose it themselves. Furthermore, the web client version of Servoy, http://www.servoy.com, will also be build on Wicket.

Note that these are only the projects I know of. There are currently over 275 subscribers to our user mailinglist so there are bound to be more than the projects I'm aware of. Our users are generating between 800 and 1000 messages a month on the user list alone. So it is quite an active community.

Vinnie, I hope this answer is more helpful than a redirect to Tapestry.
 
Martijn Dashorst
author
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After a good nights sleep, I appologize to Gregg for my aggressive message and the tone of it from yesterday evening. I already have offline contact with Gregg, but I felt it important to do this publicly. Apparently posting late at night is something I shouldn't do to often. So in good saloon fashion:

I stand by my remark that Wicket is mature for a given value of mature ;-), and of course the second, general part of the message.

To further the discussion on Wicket:

Vince, there is an excellent way to search for Wicket applications in the wild: google for 'bookmarkablePage'. That will give you amongst the API documentation and archived mailinglist messages also a couple of websites that run on Wicket. Jesse Sightler has performed such a search on his blog.
 
Anselm Paulinus
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:


Not true. Ok, there are 2 configuration files for Tapestry if you do not use .page files. There is the web.xml and the [appname].application file. If you use annotations you don't need .page files at all. But in your .application file, you have to tell it where to get all your classes that extend BasePage (or your version of BasePage) using

<meta key="org.apache.tapestry.page-class-packages" value="your.package.pages"/>


Hmm Greg; I am new to T4; I used to think that the hivemodule.xml file was one more configuration file that one has to deal with in T4; Am I wrong on that assumption?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anselm Paulinus:


Hmm Greg; I am new to T4; I used to think that the hivemodule.xml file was one more configuration file that one has to deal with in T4; Am I wrong on that assumption?


Depends. For your smaller apps you can probably get away with not needing to specify any custom services. Larger apps would probably require you to do something. However, it's more likely that you would be choosing to use Spring or HiveMind. So even if you didn't use Tapestry, you still have the config.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!