it might almost go without saying that i don't agree with these particular cons.
html templates live next to java code because they are conceptually related and so it makes sense to encapsulate them in the same package. what never made sense to me was the other way of doing it. requiring a good grasp of OO means wicket is actually a pretty good litmus test for determining who not to hire. separation of markup from code is important to designers and coders. i have been able to work alongside with a designer for months and the work is so seamless that we often go for days or even weeks without communicating. because of the split it's just not necessary. this saves a lot of time and hassle. i do agree there are cons to wicket for certain specific kinds of jobs. there are also imperfections that come to mind. but for anything that falls fairly strongly into the category of "web application" and is not something closer to "static site", i find few if any mentionable cons in using wicket day-to-day. of course, i /could/ be biased since wicket was originally designed to serve my own needs. cons - if you are not really building a web /application/, but are either doing a quickie prototype of something or you are writing something that is more like a static web site with a few dynamic bits, wicket may be overkill. you might prefer something like freemarker or ROR. if you plan to scale and maintain a web application with any real complexity, however, wicket wins in my book. flaws - the api surface area /is/ a little bigger than it would ideally be. i wish i had stayed more on top of this. fighting to remove stuff and shrink the api is half the battle of making a framework. there are even a number of things i put in there myself that i now regret. you want expressive completeness, but you also want minimality because you ideally want an api to guide people to a single right answer rather than leaving them feeling like they are swimming in options. one way of minimizing the api surface area is to hide things in objects. this makes it implicitly clear how to find them based on their location. the competing need is to make things expressive. there are a number of methods in Component in particular which are in the gray zone between the need to be expressive and the need to minimize the surface area. quite a few of these methods were guesses as to what people would do a lot. i regret making some of those guesses. in the future, i would err on the side of minimality and add convenience methods based on actual use cases and consistency instead of trying to predict usage. - wicket currently lacks support for generics. i know there are people on our core team who don't like generics because they are verbose, but i disagree with this view. this is a con i would like to see corrected in the next version. people who don't want more type safety can turn off the compiler warnings. of course, compared with most other frameworks, the fact that wicket has any type safety at all is a major pro. - the documentation and examples are scattered and sometimes out of date. we simply have not had the resources to deal with these problems. there have always been far more important things to deal with - things that affect shipping applications - to really focus on this. it's an unfortunate situation, but not something i'd personally list as a con because the ##wicket irc channel and the wicket-user list more than make up for this lacking. given the choice, i'd rather have wicket-user and no docs at all than great docs and no personal help from experts. - you can get bitten by serialization if you are not careful with anonymous classes. this is more of a java flaw though and i have submitted a request for static anonymous classes to sun. - eelco's right. java is getting annoying in its limitations. there are a lot of things we could do in wicket to improve the api that we simply can't do because of java. - i would still like to see a wicket container that eliminates the servlet API entirely and creates a zero-config environment with high performance clustering. this is, of course, a fairly major project with no financial payoff. mraible wrote: > > I didn't say my cons were valid - but I do believe there *are* cons to > Wicket. What are they - in your opinion? > > matt > > > igor.vaynberg wrote: >> >>> * HTML templates live next to Java code >> this is easily changed - just a default >> >>> * Need to have a good grasp of OO >> why is this a con? you are saying not knowing oo is a good thing? you >> can say this is a pro - learning wicket will make you a better >> developer :) >> >>> * The Wicket Way - everything done in Java >> as opposed to embedding logic in views which has been something >> plaguing other frameworks for ages? >> >> -igor >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13788209 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
