I think... We should be able to use the untyped variants, but the explanations for why that won't work directly was valid.
So on to you're A/B question. I don't think it matters much... The people doing things "inline" are going to use that method anyway and generics won't hurt them, but the usefulness to people who write more extensive application is likely more important (if its that simple it doesn't matter much, if its complicated then it is and can be used). Allow me to digress. I think that if Wicket had been written with generics from the beginning, the API would be different... And that is the root of the problem. I think that maybe a concerted refactoring effort *must* allow the API to change (call it wicket 2.0 for all of us old struts users) in order for things to work out properly. I don't actually think that heavy a refactoring would be such a bad thing. I love what Wicket has done, but I think it could be less "black-boxy" as well. - Brill -----Original Message----- From: Stefan Lindner [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 12:13 PM To: users@wicket.apache.org Subject: AW: users, please give us your opinion: what is your take on generics with Wicket Brill Pappin wrote >I don't know, I think the discussion is going *toward* generics. >Frankly I can't even see why its an issue at all, the language has evolved and uses them... Why would Wicket not also use them its inline with >the current state of the language? > >There is no reason that people who can't get their heads around Generics can't use the older releases that don't include it, but IMO any java >developer who doesn't get generics yet better make some time to learn, because like it or not, they *will* be dealing with them. I agree totally with you. My expericence with Generics over the last two years was that any project that was adopted to generics had much less errors afterwards. But the main problem in this discussion seems to be that there are two very different sorts of Web Applications that are developed with wicket and both may have predecessors that are non generic. Type A: A Web applicatons that make heavy use of Models, like classic desktop allications that are ported to the web. I think the programmers of such applications like Generics becaus they help them to avoid erros and the current wicket generic implementation leads to a strong typed application that needs a good object model (and a good database design). If you port an exisitng wicket application with no generic to wicket 1.4 you might discover some unclear object model problems in your exisitng code. And it's always easier to point to wicket's generics than to blame your own code :-) Type B: A Web Application with more static content, only some date (like user logins, user profile data). In this case it's clear that some people say "why should I always tyle 'Link<Void>', none of my links has a Model, just about 10% of my Components have a Model". But why dont't they write their own wrapper e.g. MyVoidLink extends Link<Void>? I remember a dicsusson about such Components some weeks ago. What do you think about it? Would it help users of Type B to have VoidComponents? Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
