change cursor while ajaxRequest
Hello, there is an AjaxButton in my application. This button starts a sql-statement. I want to change the cursor while this statement is executed. How can I do this with wicket? Mit freundlichen Grüßen Christoph Manig Systems Engineer T-Systems International GmbH Systems Integration - SC Travel, Transport Logistics Hoyerswerdaer Str. 18 01099 Dresden tel.: +49 (0) 351 / 8152 - 188 fax:+49 (0) 351 / 8152 - 209 email: christoph.ma...@t-systems.com
Re: Wicket mail and pdf
Does anybody know some example example code to start with concerning email and pdf Thanks in advance Heiner Braun Am 10.06.2013 10:34, schrieb Martin Grigorov: Hi, If you use Wicket 6.7.0+ then you can use ComponentRenderer class to get the markup of any Wicket Page/Panel/Component. Then you can use the generated markup for mails and PDF creation. For PDF creation you can check https://github.com/flyingsaucerproject/flyingsaucer. There is a mail in the users@ mail archives from the last few days by another user showing how to use FlyingSaucer's ITextRenderer. On Sat, Jun 8, 2013 at 8:39 PM, Piratenvisierhansheinrichbr...@yahoo.dewrote: I wanted to integrate mail and pdf creation in my wicket application. Till now I manage this by sending a request to a cocoon-2.2.0 application. This is a good solution but because I see no upgrade way using my cocoon application and integrating newer versions of spring I am looking for an alternative. Heiner --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: change cursor while ajaxRequest
Hi, The simplest solution is to use IndicatingAjaxButton. Every Ajax component/behavior can have IAjaxCallListener. You can use it to show an indicator in 'beforeSend' and hide it in 'complete' handler. There are also global Ajax listeners which you can use if you want to do something on every Ajax request (for all Ajax components in your page). See https://cwiki.apache.org/confluence/display/WICKET/Wicket+Ajax for more details On Tue, Jun 11, 2013 at 9:33 AM, christoph.ma...@t-systems.com wrote: Hello, there is an AjaxButton in my application. This button starts a sql-statement. I want to change the cursor while this statement is executed. How can I do this with wicket? Mit freundlichen Grüßen Christoph Manig Systems Engineer T-Systems International GmbH Systems Integration - SC Travel, Transport Logistics Hoyerswerdaer Str. 18 01099 Dresden tel.: +49 (0) 351 / 8152 - 188 fax:+49 (0) 351 / 8152 - 209 email: christoph.ma...@t-systems.com
Re: change cursor while ajaxRequest
Cursor depends on element you are placed at... It might be better to show some spinning wheel or busy indicator. See e.g. 1- https://cwiki.apache.org/WICKET/generic-busy-indicator-for-both-ajax-and-non-ajax-submits.html 2- http://wicketinaction.com/2008/12/preventing-double-ajax-requests-in-3-lines-of-code/ On Tue, Jun 11, 2013 at 10:33 AM, christoph.ma...@t-systems.com wrote: Hello, there is an AjaxButton in my application. This button starts a sql-statement. I want to change the cursor while this statement is executed. How can I do this with wicket? Mit freundlichen Grüßen Christoph Manig Systems Engineer T-Systems International GmbH Systems Integration - SC Travel, Transport Logistics Hoyerswerdaer Str. 18 01099 Dresden tel.: +49 (0) 351 / 8152 - 188 fax:+49 (0) 351 / 8152 - 209 email: christoph.ma...@t-systems.com -- Regards - Ernesto Reinaldo Barreiro
Re: Wicket mail and pdf
Hi, At http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?0 you can see an example of rendering the markup for a page, a panel and a resource. At http://markmail.org/message/em4wqtsxhetu4skj you can see how to create PDF out of the produced HTML. On Tue, Jun 11, 2013 at 9:39 AM, Piratenvisier hansheinrichbr...@yahoo.dewrote: Does anybody know some example example code to start with concerning email and pdf Thanks in advance Heiner Braun Am 10.06.2013 10:34, schrieb Martin Grigorov: Hi, If you use Wicket 6.7.0+ then you can use ComponentRenderer class to get the markup of any Wicket Page/Panel/Component. Then you can use the generated markup for mails and PDF creation. For PDF creation you can check https://github.com/**flyingsaucerproject/**flyingsaucerhttps://github.com/flyingsaucerproject/flyingsaucer. There is a mail in the users@ mail archives from the last few days by another user showing how to use FlyingSaucer's ITextRenderer. On Sat, Jun 8, 2013 at 8:39 PM, Piratenvisierhansheinrichbrau** n...@yahoo.de hansheinrichbr...@yahoo.dewrote: I wanted to integrate mail and pdf creation in my wicket application. Till now I manage this by sending a request to a cocoon-2.2.0 application. This is a good solution but because I see no upgrade way using my cocoon application and integrating newer versions of spring I am looking for an alternative. Heiner --** --**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apa**che.orghttp://apache.org users-unsubscribe@**wicket.apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 404 error when calling getResourceSettings().getResourceFinders()
I managed to debug, but it looks like the application is only looking for html files in the root. for example if my java file is in *com.foo.Home.java *, and the markup folder is named *markup *inside* webapp *root, it will expect the folder inside *markup/Home.html, *and then throw a*MarkupNotFoundException *since the file is not in the root. Not inside *markup/com/foo/Home.html*as I would have expected. Is there any way around this issue, or I have missed something? Regards Joseph On Mon, Jun 10, 2013 at 4:42 PM, Joseph Mokenela matooanemoken...@gmail.com wrote: Thanks a lot Martin, I had an earlier version of wicket-extensions indeed. That solved it, Thanks again. Let me debug and I will feedback on the original error. Regards, On Mon, Jun 10, 2013 at 4:33 PM, Joseph Mokenela matooanemoken...@gmail.com wrote: The line at com.mmjmicrosystems.radarmarketing.Start.main(Start.java:66) is simply the call to server.start(); on the jetty server instance. On Mon, Jun 10, 2013 at 4:26 PM, Joseph Mokenela matooanemoken...@gmail.com wrote: Thanks for the quick response Martin, I have tried to debug the application but without success, I am using jetty server and i keep getting the following stacktrace on jetty. I am using Wicket 6.8.0 INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IFormSubmitListener, method=public abstract void org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=ILinkListener, method=public abstract void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IOnChangeListener, method=public abstract void org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IRedirectListener, method=public abstract void org.apache.wicket.IRedirectListener.onRedirect()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IResourceListener, method=public abstract void org.apache.wicket.IResourceListener.onResourceRequested()] INFO - Application- [wicket.radar-marketing] init: Wicket extensions initializer WARN - AbstractLifeCycle - FAILED wicket.radar-marketing: java.lang.NoSuchMethodError: org.apache.wicket.SharedResources.add(Ljava/lang/String;Lorg/apache/wicket/Resource;)V java.lang.NoSuchMethodError: org.apache.wicket.SharedResources.add(Ljava/lang/String;Lorg/apache/wicket/Resource;)V at org.apache.wicket.extensions.ajax.markup.html.form.upload.UploadProgressBar$ComponentInitializer.init(UploadProgressBar.java:55) at org.apache.wicket.extensions.Initializer.init(Initializer.java:36) at org.apache.wicket.Application.initInitializers(Application.java:612) at org.apache.wicket.Application.initializeComponents(Application.java:521) at org.apache.wicket.Application.initApplication(Application.java:817) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:424) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:351) at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:102) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:748) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:249) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1222) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:676) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:455) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:90) at org.eclipse.jetty.server.Server.doStart(Server.java:260) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at com.mmjmicrosystems.radarmarketing.Start.main(Start.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) WARN - AbstractLifeCycle - FAILED
Possible optimization of page store manager
Hi All, We are using Wicket to develop our web application product (QuickBuild) for six years, and this makes our life a lot easier when comes to maintain our code base due to Wicket's component approach and type safe nature of Java. As our product gets more used in companies, it is not uncommon that thousands of users are accessing the application concurrently, and at peak time the server sometimes gets stressed to have slow response time. Our benchmark shows that offen the server is busy serializing pages. This is not strange as our application uses ajax heavily and every ajax call to the server triggers the page store to persist (serialize and write) the whole page on disk. To my understanding, Wicket serializes/saves stateful pages for purpose of back button support. At commit stage of every request, all touched pages will be put into session cache, and also get persisted via page store. This mechanism works but results in a lot of unnecessary page persistence. To explain it, assume below workflow: 1. User loads the stateful page and wicket creates a page instance to put in session cache, as well as persist to disk. 2. User clicks some action links (either ajax or non-ajax) subsequently to update parts of the page, but still remains in the same page instance, and the url displayed in browser remains unchanged. For every request, Wicket updates the page instance, put it into session cache, and finally persist it to disk. 3. User clicks some other links to cause new page instance being created, and Wicket does the same to put new instance in session cache and persist the new instance. Here in step 2, page persistence seems unnecessary to me except for the last request. That is to say, if a page instance is touched by many requests before switching to a different page instance, only the last touch has to persist the instance. This is because when user goes back to previous page instance, only the last saved state of that instance will be used. Based on this assumption, I modified method storeTouchedPages of PageStoreManager.java to compare ids of previous page instances (stored in session cache) and touched page instances. If they are different, persist the previous page instances. I tested the modification with several cases of page refreshing/backing and it seems that they all work correctly. Although I used Wicket for some time, I seldomly digged into Wicket internals. So probably I have missed some important factors when assuming above. Can someone here take a look at attached modification and kindly let me know if this is meaningful? Thanks Robin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Possible optimization of page store manager
Hi Robin, Thanks for your thoughts! Can you create a JIRA ticket and attach the path to it? The patch didn't make it through to the mailing list, and things tend to get lost anyway due to the amount of traffic on this list. Martijn On Tue, Jun 11, 2013 at 12:23 PM, Robin Shine ro...@pmease.com wrote: Hi All, We are using Wicket to develop our web application product (QuickBuild) for six years, and this makes our life a lot easier when comes to maintain our code base due to Wicket's component approach and type safe nature of Java. As our product gets more used in companies, it is not uncommon that thousands of users are accessing the application concurrently, and at peak time the server sometimes gets stressed to have slow response time. Our benchmark shows that offen the server is busy serializing pages. This is not strange as our application uses ajax heavily and every ajax call to the server triggers the page store to persist (serialize and write) the whole page on disk. To my understanding, Wicket serializes/saves stateful pages for purpose of back button support. At commit stage of every request, all touched pages will be put into session cache, and also get persisted via page store. This mechanism works but results in a lot of unnecessary page persistence. To explain it, assume below workflow: 1. User loads the stateful page and wicket creates a page instance to put in session cache, as well as persist to disk. 2. User clicks some action links (either ajax or non-ajax) subsequently to update parts of the page, but still remains in the same page instance, and the url displayed in browser remains unchanged. For every request, Wicket updates the page instance, put it into session cache, and finally persist it to disk. 3. User clicks some other links to cause new page instance being created, and Wicket does the same to put new instance in session cache and persist the new instance. Here in step 2, page persistence seems unnecessary to me except for the last request. That is to say, if a page instance is touched by many requests before switching to a different page instance, only the last touch has to persist the instance. This is because when user goes back to previous page instance, only the last saved state of that instance will be used. Based on this assumption, I modified method storeTouchedPages of PageStoreManager.java to compare ids of previous page instances (stored in session cache) and touched page instances. If they are different, persist the previous page instances. I tested the modification with several cases of page refreshing/backing and it seems that they all work correctly. Although I used Wicket for some time, I seldomly digged into Wicket internals. So probably I have missed some important factors when assuming above. Can someone here take a look at attached modification and kindly let me know if this is meaningful? Thanks Robin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Possible optimization of page store manager
Hi, On Tue, Jun 11, 2013 at 1:23 PM, Robin Shine ro...@pmease.com wrote: Hi All, We are using Wicket to develop our web application product (QuickBuild) for six years, and this makes our life a lot easier when comes to maintain our code base due to Wicket's component approach and type safe nature of Java. As our product gets more used in companies, it is not uncommon that thousands of users are accessing the application concurrently, and at peak time the server sometimes gets stressed to have slow response time. Our benchmark shows that offen the server is busy serializing pages. This is not strange as our application uses ajax heavily and every ajax call to the server triggers the page store to persist (serialize and write) the whole page on disk. To my understanding, Wicket serializes/saves stateful pages for purpose of back button support. At commit stage of every request, all touched pages will be put into session cache, and also get persisted via page store. This mechanism works but results in a lot of unnecessary page persistence. To explain it, assume below workflow: 1. User loads the stateful page and wicket creates a page instance to put in session cache, as well as persist to disk. 2. User clicks some action links (either ajax or non-ajax) subsequently to update parts of the page, but still remains in the same page instance, and the url displayed in browser remains unchanged. For every request, Wicket updates the page instance, put it into session cache, and finally persist it to disk. There is a difference in the behavior between Ajax and non-Ajax request. When non-Ajax - Wicket creates a new version of the page (unless #isVersioned() returns false) and stores it. So going back in the history will go over all versions/states of the page instance. When Ajax - the version (the pageId) is not incremented and the last state *overrides* the state in the page store. Later when/if the user goes back there will be only one display of that page. 3. User clicks some other links to cause new page instance being created, and Wicket does the same to put new instance in session cache and persist the new instance. Here in step 2, page persistence seems unnecessary to me except for the last request. That is to say, if a page instance is touched by many requests before switching to a different page instance, only the last touch has to persist the instance. This is because when user goes back to previous page instance, only the last saved state of that instance will be used. Based on this assumption, I modified method storeTouchedPages of PageStoreManager.java to compare ids of previous page instances (stored in session cache) and touched page instances. If they are different, persist the previous page instances. I tested the modification with several cases of page refreshing/backing and it seems that they all work correctly. Although I used Wicket for some time, I seldomly digged into Wicket internals. So probably I have missed some important factors when assuming above. Can someone here take a look at attached modification and kindly let me know if this is meaningful? At the moment serializing of the page (via JavaSerializer) is synchronous, i.e. it is executed in the http worker thread. The write to the disk is asynchronous (see AsynchronousDataStore) and is done in a different thread, so the http thread doesn't have to wait for the actual write to the disk. Maybe we can make the serialization in a separate thread too. Thanks Robin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 404 error when calling getResourceSettings().getResourceFinders()
Hi, It is not very clear what you have and what you expect, so I will explain how WebApplicationPath works. If it doesn't do what you need then you will have to create your own IResourceFinder. The signature is org.apache.wicket.core.util.file.WebApplicationPath#find(Class, String). The first argument is the Page class, e.g. class org.apache.wicket.examples.homepage.HomePage. The second argument is the full path to the resource including the locale, style and variation, e.g. org/apache/wicket/examples/homepage/HomePage_en_US.html. The constructor is org.apache.wicket.core.util.file.WebApplicationPath#WebApplicationPath(ServletContext, String path) The second argument is the path inside the web root. In your case this is markup. So you can put all your markup in src/main/webapp/markup/com/myproject/MyPage.html. If you need something like src/main/webapp/markup/MyPage.html (no package name!) then you will have to use your own IResourceFinder which will be similar to WebApplicationPath but you have to manipulate the value of the second argument to #find() method. On Tue, Jun 11, 2013 at 11:05 AM, Joseph Mokenela matooanemoken...@gmail.com wrote: I managed to debug, but it looks like the application is only looking for html files in the root. for example if my java file is in *com.foo.Home.java *, and the markup folder is named *markup *inside* webapp *root, it will expect the folder inside *markup/Home.html, *and then throw a*MarkupNotFoundException *since the file is not in the root. Not inside *markup/com/foo/Home.html*as I would have expected. Is there any way around this issue, or I have missed something? Regards Joseph On Mon, Jun 10, 2013 at 4:42 PM, Joseph Mokenela matooanemoken...@gmail.com wrote: Thanks a lot Martin, I had an earlier version of wicket-extensions indeed. That solved it, Thanks again. Let me debug and I will feedback on the original error. Regards, On Mon, Jun 10, 2013 at 4:33 PM, Joseph Mokenela matooanemoken...@gmail.com wrote: The line at com.mmjmicrosystems.radarmarketing.Start.main(Start.java:66) is simply the call to server.start(); on the jetty server instance. On Mon, Jun 10, 2013 at 4:26 PM, Joseph Mokenela matooanemoken...@gmail.com wrote: Thanks for the quick response Martin, I have tried to debug the application but without success, I am using jetty server and i keep getting the following stacktrace on jetty. I am using Wicket 6.8.0 INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IFormSubmitListener, method=public abstract void org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=ILinkListener, method=public abstract void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IOnChangeListener, method=public abstract void org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IRedirectListener, method=public abstract void org.apache.wicket.IRedirectListener.onRedirect()] INFO - RequestListenerInterface - registered listener interface [RequestListenerInterface name=IResourceListener, method=public abstract void org.apache.wicket.IResourceListener.onResourceRequested()] INFO - Application- [wicket.radar-marketing] init: Wicket extensions initializer WARN - AbstractLifeCycle - FAILED wicket.radar-marketing: java.lang.NoSuchMethodError: org.apache.wicket.SharedResources.add(Ljava/lang/String;Lorg/apache/wicket/Resource;)V java.lang.NoSuchMethodError: org.apache.wicket.SharedResources.add(Ljava/lang/String;Lorg/apache/wicket/Resource;)V at org.apache.wicket.extensions.ajax.markup.html.form.upload.UploadProgressBar$ComponentInitializer.init(UploadProgressBar.java:55) at org.apache.wicket.extensions.Initializer.init(Initializer.java:36) at org.apache.wicket.Application.initInitializers(Application.java:612) at org.apache.wicket.Application.initializeComponents(Application.java:521) at org.apache.wicket.Application.initApplication(Application.java:817) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:424) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:351) at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:102) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at
Re: Wicket context menu component
Hi thanks for help! With your explanations and MenuBehavior example I made it
work. Now one last thing is to recognize which link was chosen for context
menu. I see this documentation about callback:
(function) callback
Specifies the default callback to be used in case an item does not
expose its own callback.
The default callback behaves just like item.callback.
Example: {callback: callback: function(key, opt){ alert(Clicked on +
key + on element + opt.$trigger.attr(id)); }}
Is opt.$trigger.attr(id) what I want? How does this work out? I debugged
my select event for RequestCycleUtils.getQueryParameterValue(options) but
it returns nothing.
Here is my current working version of context menu:
public class ContextMenuBehavior extends JQueryBehavior implements
IJQueryAjaxAware {
private static final long serialVersionUID = 1L;
private String selector;
private ListMenuItem menuItems;
private MapString, MenuItem menuItemsMap = new HashMapString,
MenuItem();
private JQueryAjaxBehavior onSelectBehavior;
public ContextMenuBehavior(String selector, ListMenuItem menuItems) {
super(contextMenu);
this.selector = selector;
this.menuItems = menuItems;
for (MenuItem menuItem : menuItems) {
menuItemsMap.put(menuItem.getId(), menuItem);
}
add(new JavaScriptResourceReference(ContextMenuBehavior.class,
jquery.ui.position.js));
add(new JavaScriptResourceReference(ContextMenuBehavior.class,
jquery.contextMenu.js));
add(new CssResourceReference(ContextMenuBehavior.class,
jquery.contextMenu.css));
}
// Methods //
@Override
public void bind(Component component) {
super.bind(component);
component.add(this.onSelectBehavior = this.newOnSelectBehavior());
}
// Events //
@Override
public void onConfigure(Component component) {
super.onConfigure(component);
this.setOption(select,
this.onSelectBehavior.getCallbackFunction());
}
@Override
protected String $() {
// build menu items for jquery
StringBuilder items = new StringBuilder(items: {);
int nbOfMenuItems = menuItems.size();
for (int i = 0; i nbOfMenuItems; i++) {
MenuItem menuItem = menuItems.get(i);
items.append(').append(menuItem.getId()).append(': {name:
').append(menuItem.getTitle().getObject())
.append(', icon:
').append(menuItem.getIcon()).append('});
if (i nbOfMenuItems - 1) {
items.append(,);
}
}
items.append(});
return String.format($(function(){$.contextMenu({selector: '%s',
callback: %s, %s});});, selector,
onSelectBehavior.getCallbackFunction(), items.toString());
}
@Override
public void onAjax(AjaxRequestTarget target, JQueryEvent event) {
if (event instanceof SelectEvent) {
IMenuItem item = this.menuItemsMap.get(((SelectEvent)
event).getKey());
if (item != null) {
item.onClick(target);
}
}
}
protected JQueryAjaxBehavior newOnSelectBehavior() {
return new JQueryAjaxBehavior(this) {
private static final long serialVersionUID = 1L;
@Override
protected CallbackParameter[] getCallbackParameters() {
return new CallbackParameter[] {
CallbackParameter.explicit(key), CallbackParameter.context(options) };
}
@Override
protected JQueryEvent newEvent() {
return new SelectEvent();
}
};
}
protected static class SelectEvent extends JQueryEvent {
private final String key;
public SelectEvent() {
super();
this.key =
RequestCycleUtils.getQueryParameterValue(key).toString();
}
public String getKey() {
return this.key;
}
}
}
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-context-menu-component-tp4659306p4659381.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
Problem with AjaxRequestTarget.AbstractListener org.apache.wicket.extensions.markup.html.tree.Tree
Hi, We've recently upgraded to v6.5.0 [from 1.4.21]; we've implementation of Tree class which is now deprecated [we're still using the deprecated tree implementation - for now]. Earlier we used a custom WebRequestCycleProcessor and in the respond() method we did some cleanup related to the components which were added to AjaxRequestTarget; this we replaced by using AjaxRequestTarget.AbstractListener#onBeforeRespond() method. But the tree link click events [AjaxLink] response flow is not going through the onBeforeRespond() method. Is there any other method to use for this? Thanks, Rakesh.A -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Problem-with-AjaxRequestTarget-AbstractListener-org-apache-wicket-extensions-markup-html-tree-Tree-tp4659383.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: Problem with AjaxRequestTarget.AbstractListener org.apache.wicket.extensions.markup.html.tree.Tree
Hi, So you have registered your AjaxRequestTarget's listener via app.getAjaxRequestTargetListeners().add(...) and this listener is not used when an Ajax link in the tree is cliked, right ? I don't see a reason why this listener to be ignored. Please create a quickstart app and attach it to a ticket. On Tue, Jun 11, 2013 at 3:36 PM, iamrakesh iamrakes...@rediffmail.comwrote: Hi, We've recently upgraded to v6.5.0 [from 1.4.21]; we've implementation of Tree class which is now deprecated [we're still using the deprecated tree implementation - for now]. Earlier we used a custom WebRequestCycleProcessor and in the respond() method we did some cleanup related to the components which were added to AjaxRequestTarget; this we replaced by using AjaxRequestTarget.AbstractListener#onBeforeRespond() method. But the tree link click events [AjaxLink] response flow is not going through the onBeforeRespond() method. Is there any other method to use for this? Thanks, Rakesh.A -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Problem-with-AjaxRequestTarget-AbstractListener-org-apache-wicket-extensions-markup-html-tree-Tree-tp4659383.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: Problem with AjaxRequestTarget.AbstractListener org.apache.wicket.extensions.markup.html.tree.Tree
Hi,
Yes, we registered the listener like below
getAjaxRequestTargetListeners().add(new AjaxRequestTarget.AbstractListener()
{
@Override
public void onBeforeRespond(MapString, Component aMap,
AjaxRequestTarget aTarget) {
}
});
I'll try to create a quickstart.
Regards,
Rakesh.A
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Problem-with-AjaxRequestTarget-AbstractListener-org-apache-wicket-extensions-markup-html-tree-Tree-tp4659383p4659385.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: Wicket 6 migration (AbstractValidator has been removed)
Same here. What should you do? Implement an IValidor? Regards -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-migration-AbstractValidator-has-been-removed-tp4657184p4659386.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: Wicket 6 migration (AbstractValidator has been removed)
Hi, On Tue, Jun 11, 2013 at 5:11 PM, hfriederichs h.friederi...@ohra.nl wrote: Same here. What should you do? Implement an IValidor? AbstractValidator is still in Wicket 6.x but it is deprecated and removed in Wicket 7.x Another inconvenience that I recently found is that AbstractValidator#resourceKey() method generated a key automatically for you by using the validator's class simple name. That was a convention until now. In Wicket 7 this is no more the case :-/ Regards -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-migration-AbstractValidator-has-been-removed-tp4657184p4659386.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: Wicket 6 migration (AbstractValidator has been removed)
I've updated my guide removing AbstractValidator and reimplementing a custom validator without this deprecated class. See paragraph 10.2.5 http://code.google.com/p/wicket-guide/ Same here. What should you do? Implement an IValidor? Regards -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-migration-AbstractValidator-has-been-removed-tp4657184p4659386.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Problem with WiQuery Tab component after page reload
Hi, I've observed the following behavior with WiQuery's Tabs-component: after reloading a page with a tabs component on it (or by navigating the browser history), one can't switch the active tab anymore -- the component always jumps back. The browser makes a new request. Apparently, Wicket loads a specific page version from the page store, which is stuck on the tab. Removing the version number from the URL works as expected. Did anyone also observe this behavior, or has anyone a suggestion to workaround or fix that? The least thing I could do is to come up with a quickstart for this, which is attached. We're talking about Wicket 6.6.0 and WiQuery 6.6.0 here, I've also tried with 6.5.0. Thanks, bye Stefan quickstart.tabeventstate.tar.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Problem with WiQuery Tab component after page reload
I forgot to mention that this happens with an ITabsAjaxEvent handler installed on the Tabs component... so is this a stateful/stateless thing? Bye Stefan Stefan Renz wrote: Hi, I've observed the following behavior with WiQuery's Tabs-component: after reloading a page with a tabs component on it (or by navigating the browser history), one can't switch the active tab anymore -- the component always jumps back. The browser makes a new request. Apparently, Wicket loads a specific page version from the page store, which is stuck on the tab. Removing the version number from the URL works as expected. Did anyone also observe this behavior, or has anyone a suggestion to workaround or fix that? The least thing I could do is to come up with a quickstart for this, which is attached. We're talking about Wicket 6.6.0 and WiQuery 6.6.0 here, I've also tried with 6.5.0. Thanks, bye Stefan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- im Auftrag der eFonds Solutions AG, +49-89-579494-3417 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Problem with WiQuery Tab component after page reload
I forgot to mention that this happens with an ITabsAjaxEvent handler installed on the Tabs component... so is this a stateful/stateless thing? Bye Stefan Stefan Renz wrote: Hi, I've observed the following behavior with WiQuery's Tabs-component: after reloading a page with a tabs component on it (or by navigating the browser history), one can't switch the active tab anymore -- the component always jumps back. The browser makes a new request. Apparently, Wicket loads a specific page version from the page store, which is stuck on the tab. Removing the version number from the URL works as expected. Did anyone also observe this behavior, or has anyone a suggestion to workaround or fix that? The least thing I could do is to come up with a quickstart for this, which is attached. We're talking about Wicket 6.6.0 and WiQuery 6.6.0 here, I've also tried with 6.5.0. Thanks, bye Stefan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- im Auftrag der eFonds Solutions AG, +49-89-579494-3417 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageableListView with two rows
ListView and its subclasses do not require the use of tables. If another
style of markup is useful, use that. You can have a div with nested
divs, In fact, you could create a ProfilePanel and use a div for each.
On Mon, Jun 10, 2013 at 6:06 PM, Dan Retzlaff dretzl...@gmail.com wrote:
Maybe I just don't understand your requirements. I thought you want two
rows for each Profile. So:
add(new PageableListView(profile, profiles) {
populateItem(item) {
item.add(new Label(row1column1));
item.add(new Label(row2column1));
item.setRenderBodyOnly(true);
}
});
table
div wicket:id=profile
trtd wicket:id=row1column1/td/tr
trtd wicket:id=row2column1/td/tr
/div
/table
Obviously you can add as many columns as you'd like.
Unit testing a repeater or data table by mocking its data
Up to recently we got away with running our unit tests fully integrated with the back end db by performing live queries via our DAOs. Due to recent changes to our product schema we run into the inevitable high cost of having to spend too much time on maintain our mocked unit test data straight into the db. To cut down on that cost I would like to start mocking most of our DAOs that back-up the data tables in our product (gradually over time). Which brings me to my question, what's the recommended approach from Wicket's team (or users) on mocking the DAOs that are used by the data providers of your data tables? Our advantage is that we are using Spring and thus we could rely on spring-test, its ReflectionTestUtils but I also took a look at Mockito, EasyMock and such. I'm more curious as to what has been your experience in the past and what would you consider to be the best approach? ~ Thank you, Paul Bors
Re: Unit testing a repeater or data table by mocking its data
dear Paul, I've recently used Mockito and am quite happy with it. You can easily mock any class and make it behave as you need. Best regards Heikki Doeleman On Tue, Jun 11, 2013 at 5:08 PM, Paul Bors p...@bors.ws wrote: Up to recently we got away with running our unit tests fully integrated with the back end db by performing live queries via our DAOs. Due to recent changes to our product schema we run into the inevitable high cost of having to spend too much time on maintain our mocked unit test data straight into the db. To cut down on that cost I would like to start mocking most of our DAOs that back-up the data tables in our product (gradually over time). Which brings me to my question, what's the recommended approach from Wicket's team (or users) on mocking the DAOs that are used by the data providers of your data tables? Our advantage is that we are using Spring and thus we could rely on spring-test, its ReflectionTestUtils but I also took a look at Mockito, EasyMock and such. I'm more curious as to what has been your experience in the past and what would you consider to be the best approach? ~ Thank you, Paul Bors
Paging and excessive database access (repeaters)
Hi, I'm following the example in the repeaters section for paging through large amounts of data: http://www.wicket-library.com/wicket-examples-6.0.x/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.PagingPage Based on the example and how I've had to implement this there is a lot of data access. First is in the ContactDataProvider. The function iterator queries for the set of data that will be displayed. Next, all the objects that are returned need to be wrapped in a DetachableContactModel. The load mechanism here then loads each individual object from the datastore. In the example, the data is in memory. In a real world scenario the data is likely to be remote and this setup could have a significant performance impact. Is there some way to cut out some of the data access? For example, can I get rid of DetachableContactModel and just use the data retrieved through the ContactDataProvider? Thanks, Daniel
disable attribute escaping
Hi, looking at ComponentTag class, method writeOutput()... I suspect that is *impossible* to disable attribute escaping. I'm needing this because I use a read-only textfield, with values like iacute;, etc. where I don't want escaping. Any solution? thanks in advance - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Paging and excessive database access (repeaters)
Take a look at the Apache Wicket Cookbook: http://www.packtpub.com/article/apache-wicket-displaying-data-using-datatabl e It caches the data for the request. Also others have implemented such caching mechanism: http://opensource.55minutes.com/apidocs/fiftyfive-wicket-all/4.0/fiftyfive/w icket/data/DtoDataProvider.html I usually only cache the count() since it depends on what's in the cell after all (especially for the foreign keys when you want to display a name and not an ID). ~ Thank you, Paul Bors -Original Message- From: Daniel Watrous [mailto:dwmaill...@gmail.com] Sent: Tuesday, June 11, 2013 11:56 AM To: users@wicket.apache.org Subject: Paging and excessive database access (repeaters) Hi, I'm following the example in the repeaters section for paging through large amounts of data: http://www.wicket-library.com/wicket-examples-6.0.x/repeater/wicket/bookmark able/org.apache.wicket.examples.repeater.PagingPage Based on the example and how I've had to implement this there is a lot of data access. First is in the ContactDataProvider. The function iterator queries for the set of data that will be displayed. Next, all the objects that are returned need to be wrapped in a DetachableContactModel. The load mechanism here then loads each individual object from the datastore. In the example, the data is in memory. In a real world scenario the data is likely to be remote and this setup could have a significant performance impact. Is there some way to cut out some of the data access? For example, can I get rid of DetachableContactModel and just use the data retrieved through the ContactDataProvider? Thanks, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Security examples
Good morning, I'm having a hard time finding some solid example implementations of Wicket Auth/Roles, specifically regarding authentication. I think the documentation on the link below is well spelled out, but it would be nice to see an example of Authentication. http://wicket.apache.org/learn/projects/authroles.html The current authentication example that is linked on that page returns a 404. Also, I'm interested in hearing anyone's insight into using Apache Shiro with Wicket. Our senior management is pretty keen on seeing us implement a security framework that has a more powerful set of features. I've found Shiro to be mostly easy to implement, with the exception of managing multiple authentication realms. I was also curious to know, considering the age of Wicket Shiro, whether or not that plug-in will work with Wicket 6.8 or if it's restricted to 1.5 or earlier. Are there any problems with Wicket Auth/Roles that might be better handled with a security framework like Apache Shiro? https://github.com/wicketstuff/core/tree/core-1.5.x/jdk-1.5-parent/shiro-security Thanks so much for any input you can offer. Regards, Mike
Re: disable attribute escaping
Hi, textField.setEscapeModelStrings(false) On Tue, Jun 11, 2013 at 7:33 PM, Alfonso Quiroga alfonsose...@gmail.comwrote: Hi, looking at ComponentTag class, method writeOutput()... I suspect that is *impossible* to disable attribute escaping. I'm needing this because I use a read-only textfield, with values like iacute;, etc. where I don't want escaping. Any solution? thanks in advance - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Paging and excessive database access (repeaters)
This example is not quite optimized. The DetachableContactModel's
constructor is
public DetachableContactModel(Contact c)
{
this(c.getId());
}
but it should be:
public DetachableContactModel(Contact c)
{
this(c.getId());
setObject(c);
}
The way it's done in the example although the model is given the contact,
it stores only its id and needs to load it from the database in order to
access it, even while rendering the table. The way I suggest the model is
given the contact and does not need to load it.
So, the way it's done in the example database access is as follows:
- a list query to get the contacts for a given page
- n queries by id, one for each row
The way I'm suggesting database access is as follows:
- a list query to get the contacts for a give page
- no other queties
If the row contains say a link column that accesses the row model in the
ajax click, then you will see an additional database access by id when the
DetachableContactModel is attached.
Cheers
Marios
On Tue, Jun 11, 2013 at 6:56 PM, Daniel Watrous dwmaill...@gmail.comwrote:
Hi,
I'm following the example in the repeaters section for paging through large
amounts of data:
http://www.wicket-library.com/wicket-examples-6.0.x/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.PagingPage
Based on the example and how I've had to implement this there is a lot of
data access. First is in the ContactDataProvider. The function iterator
queries for the set of data that will be displayed.
Next, all the objects that are returned need to be wrapped in
a DetachableContactModel. The load mechanism here then loads each
individual object from the datastore.
In the example, the data is in memory. In a real world scenario the data is
likely to be remote and this setup could have a significant performance
impact.
Is there some way to cut out some of the data access? For example, can I
get rid of DetachableContactModel and just use the data retrieved through
the ContactDataProvider?
Thanks,
Daniel
Do all POJOs have to implement Serializable?
Hi, I have an existing application tier that I package as a jar and place in a maven repository. I've been working to expose some of this application through Wicket. It's easy to include it in the pom, but I keep getting: ERROR - JavaSerializer - Error serializing object MyObject ... The object type is not Serializable! Do all of my classes have to implement serializable in order to use them in Wicket? Daniel
Re: Wicket Security examples
http://www.wicket-library.com/wicket-examples/index.html See the authentication-1 through authentication-3 examples. Martijn On Tue, Jun 11, 2013 at 7:18 PM, Michael Chandler michael.chand...@onassignment.com wrote: Good morning, I'm having a hard time finding some solid example implementations of Wicket Auth/Roles, specifically regarding authentication. I think the documentation on the link below is well spelled out, but it would be nice to see an example of Authentication. http://wicket.apache.org/learn/projects/authroles.html The current authentication example that is linked on that page returns a 404. Also, I'm interested in hearing anyone's insight into using Apache Shiro with Wicket. Our senior management is pretty keen on seeing us implement a security framework that has a more powerful set of features. I've found Shiro to be mostly easy to implement, with the exception of managing multiple authentication realms. I was also curious to know, considering the age of Wicket Shiro, whether or not that plug-in will work with Wicket 6.8 or if it's restricted to 1.5 or earlier. Are there any problems with Wicket Auth/Roles that might be better handled with a security framework like Apache Shiro? https://github.com/wicketstuff/core/tree/core-1.5.x/jdk-1.5-parent/shiro-security Thanks so much for any input you can offer. Regards, Mike -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Do all POJOs have to implement Serializable?
If your component holds a reference to a pojo (either directly or via a model), then the pojo has to be serializable. If you can let go of the pojo at the end of the request (in your component's #onDetach() or your model's #detach()), then your pojo won't be serialized along with your page. Take a look at LoadableDetachableModel for an example. Sven On 06/11/2013 09:39 PM, Daniel Watrous wrote: Hi, I have an existing application tier that I package as a jar and place in a maven repository. I've been working to expose some of this application through Wicket. It's easy to include it in the pom, but I keep getting: ERROR - JavaSerializer - Error serializing object MyObject ... The object type is not Serializable! Do all of my classes have to implement serializable in order to use them in Wicket? Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket context menu component
Hi, glad to read it is almost working :) getQueryParameterValue(options) does return anything because it's not transmitted server side (due to CallbackParameter.context(options), which does not pass the parameter to the ajax callback). But even you did transmit it, you probably got an [object] string. As per your example, I would think that you are probably interested to the 'key'... But if you want to check what's happening client side, best is to debug the call to the function using Firefox with Firebug (or Chrome equivalent for instance) and see what you have in 'key' and 'options' object. Then you will know what to transmit server side via the ajax callback. For instance (I did not check the doc): CallbackParameter.resolved(menuId, options.id) Hope this helps, Sebastien.
RE: Wicket Security examples
Not sure how I missed that, thanks Martijn. -Original Message- From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] Sent: Tuesday, June 11, 2013 12:52 PM To: users@wicket.apache.org Subject: Re: Wicket Security examples http://www.wicket-library.com/wicket-examples/index.html See the authentication-1 through authentication-3 examples. Martijn On Tue, Jun 11, 2013 at 7:18 PM, Michael Chandler michael.chand...@onassignment.com wrote: Good morning, I'm having a hard time finding some solid example implementations of Wicket Auth/Roles, specifically regarding authentication. I think the documentation on the link below is well spelled out, but it would be nice to see an example of Authentication. http://wicket.apache.org/learn/projects/authroles.html The current authentication example that is linked on that page returns a 404. Also, I'm interested in hearing anyone's insight into using Apache Shiro with Wicket. Our senior management is pretty keen on seeing us implement a security framework that has a more powerful set of features. I've found Shiro to be mostly easy to implement, with the exception of managing multiple authentication realms. I was also curious to know, considering the age of Wicket Shiro, whether or not that plug-in will work with Wicket 6.8 or if it's restricted to 1.5 or earlier. Are there any problems with Wicket Auth/Roles that might be better handled with a security framework like Apache Shiro? https://github.com/wicketstuff/core/tree/core-1.5.x/jdk-1.5-parent/shi ro-security Thanks so much for any input you can offer. Regards, Mike -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Paging and excessive database access (repeaters)
So what I'm hearing is that I have to use the Detachable model, but that I
can build in some caching to prevent unnecessary datastore access.
Thanks.
On Tue, Jun 11, 2013 at 1:11 PM, Marios Skounakis msc...@gmail.com wrote:
This example is not quite optimized. The DetachableContactModel's
constructor is
public DetachableContactModel(Contact c)
{
this(c.getId());
}
but it should be:
public DetachableContactModel(Contact c)
{
this(c.getId());
setObject(c);
}
The way it's done in the example although the model is given the contact,
it stores only its id and needs to load it from the database in order to
access it, even while rendering the table. The way I suggest the model is
given the contact and does not need to load it.
So, the way it's done in the example database access is as follows:
- a list query to get the contacts for a given page
- n queries by id, one for each row
The way I'm suggesting database access is as follows:
- a list query to get the contacts for a give page
- no other queties
If the row contains say a link column that accesses the row model in the
ajax click, then you will see an additional database access by id when the
DetachableContactModel is attached.
Cheers
Marios
On Tue, Jun 11, 2013 at 6:56 PM, Daniel Watrous dwmaill...@gmail.com
wrote:
Hi,
I'm following the example in the repeaters section for paging through
large
amounts of data:
http://www.wicket-library.com/wicket-examples-6.0.x/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.PagingPage
Based on the example and how I've had to implement this there is a lot of
data access. First is in the ContactDataProvider. The function iterator
queries for the set of data that will be displayed.
Next, all the objects that are returned need to be wrapped in
a DetachableContactModel. The load mechanism here then loads each
individual object from the datastore.
In the example, the data is in memory. In a real world scenario the data
is
likely to be remote and this setup could have a significant performance
impact.
Is there some way to cut out some of the data access? For example, can I
get rid of DetachableContactModel and just use the data retrieved through
the ContactDataProvider?
Thanks,
Daniel
Re: Possible optimization of page store manager
Hi Martijn, Yes I will if the modification is valid. Right now Martin pointed to me that non-ajax action link also cause version changes, and my previous test does not cover this as I only updated model in my action link so version is not changed. I will further investigate this. Regards Robin --- On Tue, 6/11/13, Martijn Dashorst martijn.dasho...@gmail.com wrote: From: Martijn Dashorst martijn.dasho...@gmail.com Subject: Re: Possible optimization of page store manager To: users@wicket.apache.org Date: Tuesday, June 11, 2013, 6:48 PM Hi Robin, Thanks for your thoughts! Can you create a JIRA ticket and attach the path to it? The patch didn't make it through to the mailing list, and things tend to get lost anyway due to the amount of traffic on this list. Martijn On Tue, Jun 11, 2013 at 12:23 PM, Robin Shine ro...@pmease.com wrote: Hi All, We are using Wicket to develop our web application product (QuickBuild) for six years, and this makes our life a lot easier when comes to maintain our code base due to Wicket's component approach and type safe nature of Java. As our product gets more used in companies, it is not uncommon that thousands of users are accessing the application concurrently, and at peak time the server sometimes gets stressed to have slow response time. Our benchmark shows that offen the server is busy serializing pages. This is not strange as our application uses ajax heavily and every ajax call to the server triggers the page store to persist (serialize and write) the whole page on disk. To my understanding, Wicket serializes/saves stateful pages for purpose of back button support. At commit stage of every request, all touched pages will be put into session cache, and also get persisted via page store. This mechanism works but results in a lot of unnecessary page persistence. To explain it, assume below workflow: 1. User loads the stateful page and wicket creates a page instance to put in session cache, as well as persist to disk. 2. User clicks some action links (either ajax or non-ajax) subsequently to update parts of the page, but still remains in the same page instance, and the url displayed in browser remains unchanged. For every request, Wicket updates the page instance, put it into session cache, and finally persist it to disk. 3. User clicks some other links to cause new page instance being created, and Wicket does the same to put new instance in session cache and persist the new instance. Here in step 2, page persistence seems unnecessary to me except for the last request. That is to say, if a page instance is touched by many requests before switching to a different page instance, only the last touch has to persist the instance. This is because when user goes back to previous page instance, only the last saved state of that instance will be used. Based on this assumption, I modified method storeTouchedPages of PageStoreManager.java to compare ids of previous page instances (stored in session cache) and touched page instances. If they are different, persist the previous page instances. I tested the modification with several cases of page refreshing/backing and it seems that they all work correctly. Although I used Wicket for some time, I seldomly digged into Wicket internals. So probably I have missed some important factors when assuming above. Can someone here take a look at attached modification and kindly let me know if this is meaningful? Thanks Robin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Possible optimization of page store manager
Hi Martin, Thanks for your comment. My previous test of non-ajax action link only involves model change so version is not changed. If I replace parts of the page or call page.dirty() directly, the version does changed, and this makes my modfication no longer valid as I in this case Wicket directly uses instances cached in session to make the change and this makes it impossible to know version being changed by comparing cached instance and touched instance (as they always point to same object). Since ajax requests can still be optimized to only save last state of the instance before switching to new instance (although my previous modification does not work), I will further investigate this to see if this can be implemented. Regards Robin --- On Tue, 6/11/13, Martin Grigorov mgrigo...@apache.org wrote: From: Martin Grigorov mgrigo...@apache.org Subject: Re: Possible optimization of page store manager To: users@wicket.apache.org users@wicket.apache.org Date: Tuesday, June 11, 2013, 7:05 PM Hi, On Tue, Jun 11, 2013 at 1:23 PM, Robin Shine ro...@pmease.com wrote: Hi All, We are using Wicket to develop our web application product (QuickBuild) for six years, and this makes our life a lot easier when comes to maintain our code base due to Wicket's component approach and type safe nature of Java. As our product gets more used in companies, it is not uncommon that thousands of users are accessing the application concurrently, and at peak time the server sometimes gets stressed to have slow response time. Our benchmark shows that offen the server is busy serializing pages. This is not strange as our application uses ajax heavily and every ajax call to the server triggers the page store to persist (serialize and write) the whole page on disk. To my understanding, Wicket serializes/saves stateful pages for purpose of back button support. At commit stage of every request, all touched pages will be put into session cache, and also get persisted via page store. This mechanism works but results in a lot of unnecessary page persistence. To explain it, assume below workflow: 1. User loads the stateful page and wicket creates a page instance to put in session cache, as well as persist to disk. 2. User clicks some action links (either ajax or non-ajax) subsequently to update parts of the page, but still remains in the same page instance, and the url displayed in browser remains unchanged. For every request, Wicket updates the page instance, put it into session cache, and finally persist it to disk. There is a difference in the behavior between Ajax and non-Ajax request. When non-Ajax - Wicket creates a new version of the page (unless #isVersioned() returns false) and stores it. So going back in the history will go over all versions/states of the page instance. When Ajax - the version (the pageId) is not incremented and the last state *overrides* the state in the page store. Later when/if the user goes back there will be only one display of that page. 3. User clicks some other links to cause new page instance being created, and Wicket does the same to put new instance in session cache and persist the new instance. Here in step 2, page persistence seems unnecessary to me except for the last request. That is to say, if a page instance is touched by many requests before switching to a different page instance, only the last touch has to persist the instance. This is because when user goes back to previous page instance, only the last saved state of that instance will be used. Based on this assumption, I modified method storeTouchedPages of PageStoreManager.java to compare ids of previous page instances (stored in session cache) and touched page instances. If they are different, persist the previous page instances. I tested the modification with several cases of page refreshing/backing and it seems that they all work correctly. Although I used Wicket for some time, I seldomly digged into Wicket internals. So probably I have missed some important factors when assuming above. Can someone here take a look at attached modification and kindly let me know if this is meaningful? At the moment serializing of the page (via JavaSerializer) is synchronous, i.e. it is executed in the http worker thread. The write to the disk is asynchronous (see AsynchronousDataStore) and is done in a different thread, so the http thread doesn't have to wait for the actual write to the disk. Maybe we can make the serialization in a separate thread too. Thanks Robin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
bug in TableComponentAsXlsHandler
I am using the wicket poi api to generate an excel file from a
PageableListView.
I just run into a bug in lines 67-76 of TableComponentAsXlsHandler.java:
cellExplorer becomes null already at the second iteration of the for loop
(see below)
TableParser parser = new TableParser(newSheet(), cellExporter);
if (tableComponent instanceof IPageable)
{
IPageable pageable = (IPageable)tableComponent;
for (int i = 0; i pageable.getPageCount(); i++)
{
pageable.setCurrentPage(i);
parser.parse(tableComponent);
}
}
and we get a NullPointerException on line
org.wicketstuff.poi.excel.TableParser.doParse(TableParser.java:152) (see
below)
Do you have any suggestions on how to solve this problem ?
I am using wicket-poi-1.5-RC5.1.jar
SEVERE: Unexpected error occurred
java.lang.RuntimeException: Error while generating a xls file to table
component
at
org.wicketstuff.poi.excel.TableComponentAsXlsHandler.respond(TableComponentAsXlsHandler.java:91)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:97)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:123)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.__invoke(StandardHostValve.java:171)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:931)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NullPointerException
at org.wicketstuff.poi.excel.TableParser.doParse(TableParser.java:152)
at org.wicketstuff.poi.excel.TableParser.parse(TableParser.java:76)
at
org.wicketstuff.poi.excel.TableComponentAsXlsHandler.respond(TableComponentAsXlsHandler.java:74)
... 26 more
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/bug-in-TableComponentAsXlsHandler-tp4659409.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: wicket-atmosphere issues
On Tue, Mar 26, 2013 at 4:31 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: On Monday 25 March 2013 00:59:30 Leonid Bogdanov wrote: 3) In my app Apache Shiro framework is integrated via a plugin adapted from fiftyfive-wicket-shiro project. User credentials are checked in an AJAX login form. In order to prevent a session fixation attack there is a call to invalidate old and create new session right before credentials check: getSession().replaceSession(); // inside AjaxFallbackButton.onSubmit() After integration with Atmosphere this code no longer works, an exception in thrown on login attempt: cut IllegalStateException in Session I'm not sure what happens here. It seems Wicket tries to read an attribute from the invalidated session. Does this happen even without a suspended connected? I encountered this same issue, and traced it back to the AtmosphereRequest caching and returning the original session, even after it had been invalidated and replaced. I reported it upstream. https://github.com/Atmosphere/atmosphere/pull/1139 Dan
