Best Way to Perform a Quick Test
Hi, I'm just beginning with Wicket Development. I've been used to Java development where, when I want to perform a quick test, I simply add a sysout to see if a certain code segment is being reached eg. System.out.println(Segment 1 reached) or to find out what is being returned by a database call eg. System.out.println(makeDatabasecall().toString()) and so on. I know this is not the best way to debug code, but for minor projects, it makes sense to be quick testing. But as Wicket needs everything to be serialized, adding sysouts breaks the code. What is the best quick way to perform simple variable value checks (and print them out on a console/UI) using Wicket? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-Way-to-Perform-a-Quick-Test-tp4657669.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best Way to Perform a Quick Test
I think you misunderstand serialization. Only class member data is serialized, plus a small amount of metadata like the class name and a version. Normal methods, and any logging in those methods, have no effect on serialized output. If you tried printing and it didn't work, please share your code. On Mon, Apr 1, 2013 at 7:51 AM, madmax108 lifeofna...@gmail.com wrote: Hi, I'm just beginning with Wicket Development. I've been used to Java development where, when I want to perform a quick test, I simply add a sysout to see if a certain code segment is being reached eg. System.out.println(Segment 1 reached) or to find out what is being returned by a database call eg. System.out.println(makeDatabasecall().toString()) and so on. I know this is not the best way to debug code, but for minor projects, it makes sense to be quick testing. But as Wicket needs everything to be serialized, adding sysouts breaks the code. What is the best quick way to perform simple variable value checks (and print them out on a console/UI) using Wicket? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-Way-to-Perform-a-Quick-Test-tp4657669.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Does getRenderBodyOnly need to be final?
I've come across a HTML/CSS template that is sensitive to the spans wicket places in various places and would like to do a global remove of these but don't want to have to call setRenderBodyOnly(true) on every component if I can avoid it. I thought that maybe I could override getRenderBodyOnly in my app's base panel class so that all panels are automagically affected but I discovered that getRenderBodyOnly is marked as final in the framework. Is there any reason for this? It could be really useful to override this. Yours sincerely, Chris Colman Pagebloom Team Leader, Step Ahead Software pagebloom - your business your website growing together Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 Email: chr...@stepahead.com.au mailto://chr...@stepahead.com.au Website: http://www.pagebloom.com blocked::http://www.pagebloom.com/ http://develop.stepaheadsoftware.com blocked::http://develop.stepaheadsoftware.com/
Re: Does getRenderBodyOnly need to be final?
Since you have a base panel class, why not call setRenderBodyOnly() in onInitialize or onConfigure based whatever logic you planned to put in getRenderBodyOnly()? Met vriendelijke groet, Kind regards, Bas Gooren Op 1-4-2013 19:20, schreef Chris Colman: I've come across a HTML/CSS template that is sensitive to the spans wicket places in various places and would like to do a global remove of these but don't want to have to call setRenderBodyOnly(true) on every component if I can avoid it. I thought that maybe I could override getRenderBodyOnly in my app's base panel class so that all panels are automagically affected but I discovered that getRenderBodyOnly is marked as final in the framework. Is there any reason for this? It could be really useful to override this. Yours sincerely, Chris Colman Pagebloom Team Leader, Step Ahead Software pagebloom - your business your website growing together Sydney:(+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 Email: chr...@stepahead.com.au mailto://chr...@stepahead.com.au Website: http://www.pagebloom.com blocked::http://www.pagebloom.com/ http://develop.stepaheadsoftware.com blocked::http://develop.stepaheadsoftware.com/
RE: Does getRenderBodyOnly need to be final?
I was just adding it to the constructor when I realized that some AJAX aware panels need the extra spans otherwise the AJAX won't work. I might have to rethink this one. -Original Message- From: Bas Gooren [mailto:b...@iswd.nl] Sent: Tuesday, 2 April 2013 4:24 AM To: users@wicket.apache.org Subject: Re: Does getRenderBodyOnly need to be final? Since you have a base panel class, why not call setRenderBodyOnly() in onInitialize or onConfigure based whatever logic you planned to put in getRenderBodyOnly()? Met vriendelijke groet, Kind regards, Bas Gooren Op 1-4-2013 19:20, schreef Chris Colman: I've come across a HTML/CSS template that is sensitive to the spans wicket places in various places and would like to do a global remove of these but don't want to have to call setRenderBodyOnly(true) on every component if I can avoid it. I thought that maybe I could override getRenderBodyOnly in my app's base panel class so that all panels are automagically affected but I discovered that getRenderBodyOnly is marked as final in the framework. Is there any reason for this? It could be really useful to override this. Yours sincerely, Chris Colman Pagebloom Team Leader, Step Ahead Software pagebloom - your business your website growing together Sydney:(+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 Email: chr...@stepahead.com.au mailto://chr...@stepahead.com.au Website: http://www.pagebloom.com blocked::http://www.pagebloom.com/ http://develop.stepaheadsoftware.com blocked::http://develop.stepaheadsoftware.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 1.4.20 ajax download link
ajaxdownload from page history which works with 1.4 here is the code I have a ListView in a modalwindow , AJAXDownload behaviour is added to the ListItem, this list item has ajaxlink which has to start download , on click of this linkmodawindow is closed here is the code as I am closing this modal window this line target.appendJavascript(window.location.href=' + url + '); will it work? it did not start download? any advice please. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-1-4-20-ajax-download-link-tp4657649p4657675.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Tracking performance issues on requests best practices
Hello guys, I'm trying to have a finer look at what is taking time on the serverside in our application. What I have so far is that I'm using Spring AOP to track down calls to all the methods and time to the Services layer. PS: I'm using JETM http://jetm.void.fm/ (it may be old, but is simple and give pretty much what you need). 2. I've collected the time for the whole request to process in a AbstractRequestCycleListener onBeginRequest, onEndRequest so as to see a sum of the total time spent on a particular usecase. What I've expected to find is that most of the resulting time would be spent in the services layer and pretty much summed up to be near the request time on the requestcyclelistener. Practical data shows however otherwise, with the sum of the service time not even close to the total of the request time. 3. So I've fine tuned the result to also show the rendering time for the components taking as example RenderPerformanceListener which measure the time between component onBeforeRender and onAfterRender. It's pretty nice to see in jetm hierarchycal component-services call, however it still not nearly close to the whole request time. I'm still looking and seeing that there is some logic also on some component's constructors and also onInitialize() methods that I see no easy way to measure them. IComponentInitializationListener seems to only trigger after initialization, I see no easy way to mark the start time of the onInitialize() and collect the time in the listener. So I'm asking if anyone got an idea, or I'm interested what you guys usually do to track down any performance issues in the app. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Tracking-performance-issues-on-requests-best-practices-tp4657676.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Tracking performance issues on requests best practices
We use New Relic extensively, which allows us to (a) annotate key parts of the app we wish to monitor, and (b) allow profiling in production, if we ever need it. I'm not affiliated with New Relic, just a happy user of it. Please note that it's not a free tool, but given the ease of use (it's very easy to set up) I've never looked back. In case you want a free solution: run your app through a profiler to see where most time per request is spent. Met vriendelijke groet, Kind regards, Bas Gooren Op 1-4-2013 21:45, schreef Serban.Balamaci: Hello guys, I'm trying to have a finer look at what is taking time on the serverside in our application. What I have so far is that I'm using Spring AOP to track down calls to all the methods and time to the Services layer. PS: I'm using JETM http://jetm.void.fm/ (it may be old, but is simple and give pretty much what you need). 2. I've collected the time for the whole request to process in a AbstractRequestCycleListener onBeginRequest, onEndRequest so as to see a sum of the total time spent on a particular usecase. What I've expected to find is that most of the resulting time would be spent in the services layer and pretty much summed up to be near the request time on the requestcyclelistener. Practical data shows however otherwise, with the sum of the service time not even close to the total of the request time. 3. So I've fine tuned the result to also show the rendering time for the components taking as example RenderPerformanceListener which measure the time between component onBeforeRender and onAfterRender. It's pretty nice to see in jetm hierarchycal component-services call, however it still not nearly close to the whole request time. I'm still looking and seeing that there is some logic also on some component's constructors and also onInitialize() methods that I see no easy way to measure them. IComponentInitializationListener seems to only trigger after initialization, I see no easy way to mark the start time of the onInitialize() and collect the time in the listener. So I'm asking if anyone got an idea, or I'm interested what you guys usually do to track down any performance issues in the app. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Tracking-performance-issues-on-requests-best-practices-tp4657676.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Tracking performance issues on requests best practices
We use JProfiler, but Ive also used Yourkit (both very good profilers). N On Mon, Apr 1, 2013 at 3:45 PM, Serban.Balamaci thespamtr...@gmail.comwrote: Hello guys, I'm trying to have a finer look at what is taking time on the serverside in our application. What I have so far is that I'm using Spring AOP to track down calls to all the methods and time to the Services layer. PS: I'm using JETM http://jetm.void.fm/ (it may be old, but is simple and give pretty much what you need). 2. I've collected the time for the whole request to process in a AbstractRequestCycleListener onBeginRequest, onEndRequest so as to see a sum of the total time spent on a particular usecase. What I've expected to find is that most of the resulting time would be spent in the services layer and pretty much summed up to be near the request time on the requestcyclelistener. Practical data shows however otherwise, with the sum of the service time not even close to the total of the request time. 3. So I've fine tuned the result to also show the rendering time for the components taking as example RenderPerformanceListener which measure the time between component onBeforeRender and onAfterRender. It's pretty nice to see in jetm hierarchycal component-services call, however it still not nearly close to the whole request time. I'm still looking and seeing that there is some logic also on some component's constructors and also onInitialize() methods that I see no easy way to measure them. IComponentInitializationListener seems to only trigger after initialization, I see no easy way to mark the start time of the onInitialize() and collect the time in the listener. So I'm asking if anyone got an idea, or I'm interested what you guys usually do to track down any performance issues in the app. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Tracking-performance-issues-on-requests-best-practices-tp4657676.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ModalWindow: setWindowClosedCallback has access to old model or change to modal window's model goes away ?
I think that the issue has something to do with the fact that WindowClosedCallBack is a Behavior, and in the wicket.Behavior I find the note: * p * You also cannot modify a components model with a behavior. * /p I am not modifying the model of the window through the windowClosedCallBack, but does this note also mean that I cannot expect the behavior to hold a reference to an updated model of the component (my modal window) ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ModalWindow-setWindowClosedCallback-has-access-to-old-model-or-change-to-modal-window-s-model-goes-a-tp4657672p4657679.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ModalWindow: setWindowClosedCallback has access to old model or change to modal window's model goes away ?
It seems that the model of the modal window is read before his behavior responds, and it is not re-read after the behavior responds. How to get around this ? Nobody has a suggestion ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ModalWindow-setWindowClosedCallback-has-access-to-old-model-or-change-to-modal-window-s-model-goes-a-tp4657672p4657680.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ModalWindow: setWindowClosedCallback has access to old model or change to modal window's model goes away ?
I have tried to detach the model of the modal window in the onclick, and to
reset it, but to no avail. I think that trying to manipulate teh model of
the modal window for my purpose will not work at all.
So, I have tried in the onClick to redirect to intercept page this way:
modalPageReference.getPage().redirectToInterceptPage(new
SecondPage(parameters));
window.close(target);
Then, I have modified the windowClosedCallBack this way:
window.setWindowClosedCallback(new ModalWindow.WindowClosedCallback() {
private static final long serialVersionUID = 1L;
@Override
public void onClose(AjaxRequestTarget target) {
modalPageReference.getPage().continueToOriginalDestination();
}
});
The only problem is that he SecondPage is rendered within the modal window,
and I would like to close it and use the window of the main page ...
Anyone interested in helping out with this ?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/ModalWindow-setWindowClosedCallback-has-access-to-old-model-or-change-to-modal-window-s-model-goes-a-tp4657672p4657681.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
