Re: [Wicketstuff 1.5] Code formatting
IMHO Formatting should be done on commit. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-1-5-Code-formatting-tp3432552p3433490.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: [Wicketstuff 1.5] Code formatting
jer...@wickettraining.com wrote: 1 - formatting CAN break code (I know it doesn't usually, but can), We have done post-commit-hook-formatting on a big project and luckily never had a code break. But theoretically you're absolutely right. 2 - the statement that everyone can format how he or she likes is FALSE. If I check-in my 16-char tabulation file and you check in your 2-tab-per-tab-tabulation file, and both are transformed to three-spaces-two-commas-and-a-pipe formatting (yes, I'm making that stuff up) when I check out my file, I get the re-formatted version, and so does two-tab guy. So NEITHER of us is working with the same format we like / checked in. I think we have a misunderstanding here. If I checkin my code then it is reformatted by the commit-hook and I get back the formatted code in my workspace immediately (like with expanding those CVS variables you can embed in your code). This way the history only shows the changes I really made and there is no mess up of the history because of changes caused by formatting. Anyhow, with commit-hook-formatting we made very good experience. Developers really can format the way they like, or at least do not need to bother at all with plugins, settings, etc. As soon as they checkin, their code is formatted on the server *and* in their workspace. when I check out my file, I get the re-formatted version, and so does two-tab guy. So NEITHER of us is working with the same format we like No, you get the re-formatted version when you check in. You don't care about formatting until checkin. No need to make sure the formatting is conform the rules. commit-hook takes care about that. That's the only difference. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-1-5-Code-formatting-tp3432552p3435345.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: final Page.onInitialize()
Hi, Clint Checketts wrote: I don't believe the goal of onInitiallize is to move all component creation from the constructor to onInitialize, since if you are adding the component to the parent in the onInitialize method then you are back to the problem of not being able to call getPage() in your components. I think it is the opposite: if I create and add components in their respective constructors I do not have access to getPage(): class MyPage { MyPage() { add(new MyPanel()); } } class MyPanel { MyPanel() { log.debug(getPage() = + getPage()); = null add(new Label(id, getString(resKey)); = does not resolve } } So at least in my panels and other containers I would keep creating components in onInitialize(). Is that right? Overridable factory methods in my base page (which should not be called from the constructor) are mainly there to create Components, so from where can they be called if I can't override onInitialize()? I would not like to go back to onBeforeRender and maintain a flag myself. Cheers Hans -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3298712.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: final Page.onInitialize()
Hi, After onInitialize was introduced in 1.4.12 we have done a lot of refactoring in a lot of pages to get component-creation out of the constructors and into onInitialize. Especially calling overridable factory methods from a constructor is gone now which we and PMD really appreciate. Carl-Eric Menzel-7 wrote: I think this could be sufficiently guarded by putting a good explanation on onInitialize's javadoc. Besides, by this logic, Component is also incompletely initialized until the moment it gets added to the page. Ack +1 for Carl-Eric's patch Cheers Hans -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3253718.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.