Re: [Wicketstuff 1.5] Code formatting

2011-04-07 Thread Hans Lesmeister 2
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

2011-04-07 Thread Hans Lesmeister 2

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()

2011-02-10 Thread Hans Lesmeister 2

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()

2011-02-02 Thread Hans Lesmeister 2

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.