Gili,
You are contradicting yourself. First you say that Wicket isn't ready for production use, and then you say some big ass companies need to use it. Guess what, those big ass companies aren't going to use Wicket when we keep saying that Wicket isn't ready for production use.
Well, it isn't and my point is that until we meet all the requirements of big companies we won't be ready for prime time.
> Furthermore, the project Eelco is working on is not just a pet project for Eelco, it
is (given the current exchange rate for euro's and dollars ;-) ) pretty expensive stuff and will become mission critical for that company.
I understand that. But it is still one person and one company. There is no way his website will cover all the functionality of Wicket and that's exactly what I am advocating: better coverage of our entire framework. It might be that some parts work very well but others are crap.
Wicket is ready for production use the moment we release 1.0. I don't think you should use Wicket for pacemakers, or controlling nuclear powerplants, but that is also true for Linux and almost all software. I *do* think that Wicket is ready for most web applications, be it small or large. Of course we are going to find bugs, problems and what not. But we *never* can foresee all uses. Should that prohibit us promoting Wicket? Should we withhold Wicket from all those developers strugling to keep their HTML files, XML binding files and java code consistent just because *you* think Wicket is 'not production ready'?
All I was offering was my opinion and it has been echoed by others before (maybe not on this mailing list) as to the fact that Wicket plays around with small example websites but does not have an extensive coverage by more complex stuff.
I looked at the bug list, and couldn't find any performance related issue open. Yes, I think that it is possible to write performance hogs in Wicket, but you have to do some pretty ignorant stuff in order to create one. As such, creating performance hogs is also easily done in Struts, Maverick, Cocoon, WebWork, etc. All it takes is ignorance and not performing scalability tests.
I filed a bug report a while back about how poorly the performance degraded (versus JSP) when you'd add ten or more static images. It was insane or slow it was. I don't know what became of this issue but this was just one of many open ended issues. I just don't think you can truthfully say: "hey! we're ready!" when in all honesty you are ready for the small subset of examples you have tried. You *will* run into stuff you haven't seen before. I'm talking more about performance issues or inability to code some things in Wicket (i.e. no workarounds, no functionality for doing it) than someone running into simple bugs.
Believe it or not, Wicket is production ready when we ship 1.0. I know, because I use it!
That's fine, it's your decision to make :) I don't see why I am getting such heat for restating what others have said before. Your work is appreciated and as I've said 1001 times before, Wicket has a very nice design to it but looking at the big picture I wouldn't consider it safe to use in any corporate project within the next 6 months. Eelco is lucky in that he is one of the core developers and he's all buddy buddy with the rest of the core team. If he runs into any major problems with his project, you can be sure he'll have a fix ready for it within the week's end. Others of us, on the outside, have no such leverage.
Gili
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
