you made a radical statement, just wandering if there is anything concrete you can back it up with. in my head the generics have very little effect on the actual api design so i am wandering what prompted you to say that wicket api needs a radical refactoring in order to support generics - which essentially are little more then metadata.
-igor On Mon, Jun 2, 2008 at 8:50 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: > So am I :) > > I think that just like TDD generates a whole new structure to your code (IMO > a better one) that implementing generics at the start would have produced > something a bit different. > > - Brill Pappin > > -----Original Message----- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Monday, June 02, 2008 11:42 PM > To: users@wicket.apache.org > Subject: Re: users, please give us your opinion: what is your take on > generics with Wicket > > im really curious to hear what these changes would be... > > -igor > > On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: >> >> 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] >> >> > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
