change cursor while ajaxRequest

2013-06-11 Thread Christoph.Manig
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

2013-06-11 Thread Piratenvisier

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

2013-06-11 Thread Martin Grigorov
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

2013-06-11 Thread Ernesto Reinaldo Barreiro
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

2013-06-11 Thread Martin Grigorov
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()

2013-06-11 Thread Joseph Mokenela
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

2013-06-11 Thread Robin Shine
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

2013-06-11 Thread Martijn Dashorst
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

2013-06-11 Thread Martin Grigorov
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()

2013-06-11 Thread Martin Grigorov
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

2013-06-11 Thread bronius
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

2013-06-11 Thread iamrakesh
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

2013-06-11 Thread Martin Grigorov
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

2013-06-11 Thread iamrakesh
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)

2013-06-11 Thread hfriederichs
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)

2013-06-11 Thread Martin Grigorov
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)

2013-06-11 Thread Andrea Del Bene
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

2013-06-11 Thread Stefan Renz
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

2013-06-11 Thread Stefan Renz
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

2013-06-11 Thread Stefan Renz
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

2013-06-11 Thread Eric Jablow
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

2013-06-11 Thread Paul Bors
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

2013-06-11 Thread heikki
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)

2013-06-11 Thread Daniel Watrous
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

2013-06-11 Thread Alfonso Quiroga
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)

2013-06-11 Thread Paul Bors
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

2013-06-11 Thread Michael Chandler
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

2013-06-11 Thread Martin Grigorov
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)

2013-06-11 Thread Marios Skounakis
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?

2013-06-11 Thread Daniel Watrous
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

2013-06-11 Thread Martijn Dashorst
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?

2013-06-11 Thread Sven Meier
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

2013-06-11 Thread Sebastien
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

2013-06-11 Thread Michael Chandler
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)

2013-06-11 Thread Daniel Watrous
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

2013-06-11 Thread Robin Shine
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

2013-06-11 Thread Robin Shine
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

2013-06-11 Thread grazia


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

2013-06-11 Thread Dan Retzlaff
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