Re: RestartResponseAtInterceptPageException#continueToOriginalDestination

2013-06-29 Thread martin.dilger
That sounds like a pretty good thing. Should I file a Ticket? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/RestartResponseAtInterceptPageException-continueToOriginalDestination-tp4659907p4659920.html Sent from the Forum for Wicket Core developers mailing list

RestartResponseAtInterceptPageException#continueToOriginalDestination

2013-06-28 Thread martin.dilger
Hi, just wondering, is there any Reason why RestartResponseAtInterceptPageException#continueToOriginalDestination is Package-Private and not public? It is called in Component#continueToOriginalDestination which is itself non-static. In my Mind,

Re: RestartResponseAtInterceptPageException#continueToOriginalDestination

2013-06-28 Thread martin.dilger
Hi Martin, image the typical SignIn-Functionality. You have a SignInPanel which only shows the necessary Form Components. Then you have some sort of Bean like SignInActionXYZ, which has in its perform method the typical flow: if(signInSuccesful()){ //well, check if there was some

Re: RestartResponseAtInterceptPageException#continueToOriginalDestination

2013-06-28 Thread martin.dilger
oh it is backed by wicket (what else?:)) but I dont want to clutter my components with all this stuff when it is propably reasonable to place it somewhere else. In my case, the virtual SignInAction would handle everything, not the component, the component is only the wrapper for ui etc. --

Re: RestartResponseAtInterceptPageException#continueToOriginalDestination

2013-06-28 Thread martin.dilger
Maybe an addition, dont get me wrong, everything is possible the way it is. I´m just asking for convenience to declutter some of my components. -- View this message in context:

Re: RestartResponseAtInterceptPageException#continueToOriginalDestination

2013-06-28 Thread martin.dilger
Hi Igor, We dont talk about different layers. Even if my class would be named SignInAction, it belongs to the UI-Layer and thats the only valid place, thats completely right. Could be a Spring Bean for example, that throws some use case specific authentication - exceptions (AuthenticationFailed,

Re: Deprecating wicket:enclosure

2013-06-18 Thread martin.dilger
Just to give my 3 pens, I agree with Igor too, wicket:enclosure/ is really handy in most cases, I would strongly disagree to remove it. We use it a lot in our projects and rarely have problems with it. And if I think of the impact it would have for our projects to refactor everything to use

Re: [vote] release wicket 1.5.5

2012-03-07 Thread martin.dilger
I updated my Toy-Project, all Tests are green, everything looks nice. so non-binding +1 from me. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-release-wicket-1-5-5-tp4446882p4453758.html Sent from the Forum for Wicket Core developers mailing list archive at

Re: [vote] release wicket 1.5.2 take 3

2011-10-23 Thread martin.dilger
+1 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-release-wicket-1-5-2-take-3-tp3922463p3930044.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.