just thinking out loud, there is no workaround for the constructor pros. are there any important things people really /need/ to get done that we're making impossible without the constructor change? i don't care to much about accessing markup attributes in the constructor because i don't care much about driving code from markup. but what about the others? are there any useful things we'd lose?
i think i can live without the perfect error reporting as wicket error reporting seems good enough to me now. it's almost certainly not worth a code explosion to get this alone. jon igor.vaynberg wrote: > > pros: > > * free to call any method in the constructor like getpage(), urlfor(), > etc. > > * access to markup attributes in constructor as opposed to render time > > * fail at component instantiation time rather then render time if there is > a > hierarchy<->java mismatch - so you get a java line-precise error as > opposed > to our error webpage > > cons: > > * code explosion > 2.0: http://papernapkin.org/pastebin/view/4900 > 1.3: http://papernapkin.org/pastebin/view/4908 > > * hacks necessary for nontrivial components > GridView.populate() > http://papernapkin.org/pastebin/view/4902 > notice fake1,fake2 parents necessary for child item instantiation and > which > are later removed > > * more limited in how the hierarchy is created since it MUST be created > top-down > > * replacing components is less explicit. > 1.3: a.replaceWith(new B()); > 2.0: new B(a.getParent(), a.getId()); > > -igor > > > > > On 3/6/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> >> i would like to see a list of what we'd lose by not supporting the >> constructor change. i actually prefer the add() usage and always >> have. i just don't want us to forget why we originally wanted to >> make the constructor change. the only two things i can recall are: >> >> - better diagnostics, but i can't recall exactly /what/ diagnostics we >> thought we'd get >> >> - ability to make component init dependent on parental context. this >> might >> be either xml association or component data somehow. i can't think of >> any >> times i've been screaming to do this, but can anyone give some of the >> best >> examples so we can evaluate what we'd be losing here? >> >> >> Eelco Hillenius wrote: >> > >> > Hi, >> > >> > We (Wicket's developers) are having some discussion over 1.3 vs 2.0 >> > and how difficult it is as a nun-funded project to spend so much time >> > synchronizing the branches. >> > >> > A major issue in the discussion is that not everyone is convinced >> > anymore that the constructor change in 2.0 is for the better. There >> > are pros and cons for sure, but we want to get your opinion on this. >> > >> > Please help us out giving your opinion. We want to know: >> > >> > 1) Who uses 2.0 for serious projects? >> > >> > 2) What do you think of the constructor change? Do you prefer 1.3's >> > add style or 2.0's style of passing in the parent construction time. >> > >> > 3) If we would ever backtrack on the constructor change (*if*, don't >> > panic for now) how much trouble would that give you? >> > >> > Please don't be shy giving your opinion. This is an important issue in >> > the future development of Wicket. >> > >> > Regards, >> > >> > Eelco >> > >> > >> ------------------------------------------------------------------------- >> > Take Surveys. Earn Cash. Influence the Future of IT >> > Join SourceForge.net's Techsay panel and you'll get the chance to share >> > your >> > opinions on IT & business topics through brief surveys-and earn cash >> > >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> > _______________________________________________ >> > Wicket-user mailing list >> > Wicket-user@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/wicket-user >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9342589 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Wicket-user mailing list >> Wicket-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wicket-user >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > > -- View this message in context: http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9343011 Sent from the Wicket - User mailing list archive at Nabble.com. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
