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]
