how to implement a decorator
I'm trying to figure out how to implement a decorator tag. Here's what I
mean:
I want:
to render to:
FOO!
with nothing more than the usual "add( new Label( "modBoxText", "FOO!" ) )"
in the panel class. Note that this is different than a border since there
is no add() for the decorator. The goal of this is to create reusable ui
elements that can be inserted into markup without requiring any wiring in
the java class. From what I understand, this _should_ be possible.
I tried to do this with an IComponentResolver by creating an instance of a
border, but I quickly ran into trouble with the component hierarchy when I
did this and tried to add components to the content of the decorator (such
as ). Here are the artifacts for this
to get an idea:
ModBoxBorderResolver.java
public class ModBoxBorderResolver implements IComponentResolver {
@Override
public Component resolve( MarkupContainer container, MarkupStream
markupStream, ComponentTag tag ) {
if( tag instanceof WicketTag ) {
String tagName = tag.getName();
if( tag.getName().equalsIgnoreCase( "modBox" ) ) {
return ModBoxBorder( "modBox" );
}
}
return null;
}
}
ModBoxBorder.java
public class ModBoxBorder extends Border {
...
}
ModBoxBorder.html
http://wicket.apache.org";>
I also notice BorderBehavior whihc might be another avenue, but I'm not
sure exactly how I could get this to work simply by adding tags to the
markup and an IComponentResolver.
Has anyone done anything like this already? Perhaps there is something
already in Wicket that I'm overlooking.
Re: problem with page refresh
Hi Ale. I had a very similar problem, and I was able to get the behavior I
expected by changing the render strategy to ONE_PASS_RENDER in
Application.init(). Have a look at this
http://apache-wicket.1842946.n4.nabble.com/refresh-and-AjaxFallbackDefaultDataTable-td4384935.html
On Wed, Apr 18, 2012 at 7:12 AM, alezx wrote:
> Hi guys, I ran into a problem lately,
>
> I have an instance variable in my panel and an ajax behaviour
>
> public final class ScrollLoader extends Panel implements IHeaderContributor
> {
>
> int number = 0;
> private AbstractDefaultAjaxBehavior b;
> ..
>
> //constructor
> public Scrolloader (...){
> b = new AbstractDefaultAjaxBehavior() {
>@Override
>protected void respond(AjaxRequestTarget target) {
>System.out.println("number is "+number);
>number++;
>}
> }
> ..
> }
> }
>
> when I click a button on the page, with ajax I call this behaviour and the
> number is incremented.
>
> if I click on the buttons 5 times, the number increments to 0,1,2,3,4,
> then if I refresh the page and than click on the button other 5 times, the
> number goes to 9 (5,6,7,8,9)
>
> //so far, so good!
>
> but now if I refresh the page again, and I click on the button the number
> starts incrementing from 4 and not from 9!! (so If I press the button 5
> times I see again 5,6,7,8,9 and not 10,11,12..)
>
>
> same problem when I load the page for the first time:
>
> If I *refresh * the page before incrementing the value, the number starts
> incrementing from 0
> so i get 0,1,2,3,4
> if I refresh again, the number starts incrementing from 0 again..
>
> in other words when I refresh the page 2, 3, 4 times, the number starts
> incrementing from the value reached before the first refresh, after that
> first refresh any change to the number is lost..
>
> so what do I do wrong?
>
> sorry if this is a bit confusing,
>
> and thanks for your help!
>
> ale
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/problem-with-page-refresh-tp4567392p4567392.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 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
I looked into wicket-jee but this won't do for me.
I don't think this problem is Wicket related in any event. Here are some
links I came across.
- https://community.jboss.org/thread/179757
- http://java.net/jira/browse/GLASSFISH-12599
- https://community.jboss.org/thread/179324#comment105426
- https://issues.jboss.org/browse/WELD-290
For now I have a workaround. I can i@Inject a SLSB into an
@ApplicationScoped component, and @Inject this into Wicket Pages. These
make it through serialization intact. It's not pretty, but it works for now
and will buy me some time to get to the bottom of this.
On Thu, Apr 12, 2012 at 11:56 AM, Jonathan Tougas wrote:
> I'll check it out thanks!
>
>
> On Thu, Apr 12, 2012 at 11:33 AM, Igor Vaynberg
> wrote:
>
>> weld doesnt wrap ejbs in serializable proxies. if you want to inject
>> ejbs you should do it with wicket-jee module found in wicketstuff.
>>
>> -igor
>>
>> On Thu, Apr 12, 2012 at 5:55 AM, Jonathan Tougas
>> wrote:
>> > @Override
>> >protected void onBeforeRender() {
>> >System.out.println( foo );
>> >System.out.println( foo.getClass() );
>> >super.onBeforeRender();
>> >}
>> >
>> > When using @Stateless, the output is :
>> >
>> > 08:52:35,027 INFO [stdout] (http--127.0.0.1-8080-1) Proxy for view
>> class:
>> > com.foo.FooStateless of EJB: FooStateless
>> > 08:52:35,028 INFO [stdout] (http--127.0.0.1-8080-1) class
>> > com.foo.FooStateless$Proxy$_$$_Weld$Proxy$
>> >
>> > when using @ApplicationScoped, the output is:
>> >
>> > 08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4)
>> > com.foo.FooStateless@201a6e9
>> > 08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4) class
>> > com.foo.FooStateless$Proxy$_$$_WeldClientProxy
>> >
>> >
>> > On Thu, Apr 12, 2012 at 8:46 AM, Martin Grigorov > >wrote:
>> >
>> >> The difference is that scoped beans are represented by proxy.
>> >> I guess there is no proxy for the stateless EJB. You can verify this
>> >> by putting a breakpoint in your page's #onBeforeRender() and checking
>> >> the type of the injected value.
>> >>
>> >> Later during deserialization the current class loader cannot load
>> >> class org.jboss.msc.service.ServiceName.
>> >> In the case with scoped bean the proxy is loaded without problems and
>> >> it seems the proxy itself deals with the class loading of the
>> >> underlying bean.
>> >>
>> >> On Thu, Apr 12, 2012 at 3:40 PM, Jonathan Tougas
>> >> wrote:
>> >> > I'm not familiar with the Wicketopia source, but doing a quick scan I
>> >> can't
>> >> > find any EJBs in there. The problem in this case occurs if the
>> >> FooStateless
>> >> > class is @Stateless. Changing this to @ApplicationScoped, the problem
>> >> goes
>> >> > away.
>> >> >
>> >> > On Thu, Apr 12, 2012 at 8:28 AM, Jonathan Tougas
>> >> wrote:
>> >> >
>> >> >> A stateless bean is injected into the home page class. Load the
>> page in
>> >> >> two tabs (so twice in the same session), then on the first tab,
>> press
>> >> the
>> >> >> button. The error occurs every time in this scenario.
>> >> >>
>> >> >> On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov <
>> mgrigo...@apache.org
>> >> >wrote:
>> >> >>
>> >> >>> Hi,
>> >> >>>
>> >> >>> On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas <
>> jtou...@gmail.com>
>> >> >>> wrote:
>> >> >>> > I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to
>> the
>> >> >>> mix.
>> >> >>> > In certain cases when Wicket deserializes a Page containing a
>> >> reference
>> >> >>> to
>> >> >>> > a CDI bean, I get this exception:
>> >> >>>
>> >> >>> In what cases exactly ?
>> >> >>> Because the problem is
>> >> >>>
>> >> >>> Caused by: java.lang.ClassNotFoundException:
>> >> >>> org.jboss.msc.service.ServiceName from [Module
>> >> >>> "deployment.wicket.war:main"
>> >> >>> from
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
I'll check it out thanks!
On Thu, Apr 12, 2012 at 11:33 AM, Igor Vaynberg wrote:
> weld doesnt wrap ejbs in serializable proxies. if you want to inject
> ejbs you should do it with wicket-jee module found in wicketstuff.
>
> -igor
>
> On Thu, Apr 12, 2012 at 5:55 AM, Jonathan Tougas
> wrote:
> > @Override
> >protected void onBeforeRender() {
> >System.out.println( foo );
> >System.out.println( foo.getClass() );
> >super.onBeforeRender();
> >}
> >
> > When using @Stateless, the output is :
> >
> > 08:52:35,027 INFO [stdout] (http--127.0.0.1-8080-1) Proxy for view
> class:
> > com.foo.FooStateless of EJB: FooStateless
> > 08:52:35,028 INFO [stdout] (http--127.0.0.1-8080-1) class
> > com.foo.FooStateless$Proxy$_$$_Weld$Proxy$
> >
> > when using @ApplicationScoped, the output is:
> >
> > 08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4)
> > com.foo.FooStateless@201a6e9
> > 08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4) class
> > com.foo.FooStateless$Proxy$_$$_WeldClientProxy
> >
> >
> > On Thu, Apr 12, 2012 at 8:46 AM, Martin Grigorov >wrote:
> >
> >> The difference is that scoped beans are represented by proxy.
> >> I guess there is no proxy for the stateless EJB. You can verify this
> >> by putting a breakpoint in your page's #onBeforeRender() and checking
> >> the type of the injected value.
> >>
> >> Later during deserialization the current class loader cannot load
> >> class org.jboss.msc.service.ServiceName.
> >> In the case with scoped bean the proxy is loaded without problems and
> >> it seems the proxy itself deals with the class loading of the
> >> underlying bean.
> >>
> >> On Thu, Apr 12, 2012 at 3:40 PM, Jonathan Tougas
> >> wrote:
> >> > I'm not familiar with the Wicketopia source, but doing a quick scan I
> >> can't
> >> > find any EJBs in there. The problem in this case occurs if the
> >> FooStateless
> >> > class is @Stateless. Changing this to @ApplicationScoped, the problem
> >> goes
> >> > away.
> >> >
> >> > On Thu, Apr 12, 2012 at 8:28 AM, Jonathan Tougas
> >> wrote:
> >> >
> >> >> A stateless bean is injected into the home page class. Load the page
> in
> >> >> two tabs (so twice in the same session), then on the first tab, press
> >> the
> >> >> button. The error occurs every time in this scenario.
> >> >>
> >> >> On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov <
> mgrigo...@apache.org
> >> >wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas <
> jtou...@gmail.com>
> >> >>> wrote:
> >> >>> > I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to
> the
> >> >>> mix.
> >> >>> > In certain cases when Wicket deserializes a Page containing a
> >> reference
> >> >>> to
> >> >>> > a CDI bean, I get this exception:
> >> >>>
> >> >>> In what cases exactly ?
> >> >>> Because the problem is
> >> >>>
> >> >>> Caused by: java.lang.ClassNotFoundException:
> >> >>> org.jboss.msc.service.ServiceName from [Module
> >> >>> "deployment.wicket.war:main"
> >> >>> from Service Module Loader]
> >> >>>
> >> >>> In what cases this class is no more loadable by the current class
> >> loader ?
> >> >>>
> >> >>> >
> >> >>> > 15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack]
> >> >>> > (http--127.0.0.1-8080-1) Error detaching RequestHandler:
> >> >>> > java.lang.RuntimeException: Could not deserialize object using:
> class
> >> >>> >
> >> >>>
> >>
> org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream
> >> >>> > at
> >> >>> >
> >> >>>
> >>
> org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137)
> >> >>> > [wicket-core-1.5.5.jar:1.5.5]
> >> >>> > at
> >> >>> >
> >> >>>
> >>
> org.apache.wicket.pageStore.DefaultP
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
@Override
protected void onBeforeRender() {
System.out.println( foo );
System.out.println( foo.getClass() );
super.onBeforeRender();
}
When using @Stateless, the output is :
08:52:35,027 INFO [stdout] (http--127.0.0.1-8080-1) Proxy for view class:
com.foo.FooStateless of EJB: FooStateless
08:52:35,028 INFO [stdout] (http--127.0.0.1-8080-1) class
com.foo.FooStateless$Proxy$_$$_Weld$Proxy$
when using @ApplicationScoped, the output is:
08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4)
com.foo.FooStateless@201a6e9
08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4) class
com.foo.FooStateless$Proxy$_$$_WeldClientProxy
On Thu, Apr 12, 2012 at 8:46 AM, Martin Grigorov wrote:
> The difference is that scoped beans are represented by proxy.
> I guess there is no proxy for the stateless EJB. You can verify this
> by putting a breakpoint in your page's #onBeforeRender() and checking
> the type of the injected value.
>
> Later during deserialization the current class loader cannot load
> class org.jboss.msc.service.ServiceName.
> In the case with scoped bean the proxy is loaded without problems and
> it seems the proxy itself deals with the class loading of the
> underlying bean.
>
> On Thu, Apr 12, 2012 at 3:40 PM, Jonathan Tougas
> wrote:
> > I'm not familiar with the Wicketopia source, but doing a quick scan I
> can't
> > find any EJBs in there. The problem in this case occurs if the
> FooStateless
> > class is @Stateless. Changing this to @ApplicationScoped, the problem
> goes
> > away.
> >
> > On Thu, Apr 12, 2012 at 8:28 AM, Jonathan Tougas
> wrote:
> >
> >> A stateless bean is injected into the home page class. Load the page in
> >> two tabs (so twice in the same session), then on the first tab, press
> the
> >> button. The error occurs every time in this scenario.
> >>
> >> On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov >wrote:
> >>
> >>> Hi,
> >>>
> >>> On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas
> >>> wrote:
> >>> > I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to the
> >>> mix.
> >>> > In certain cases when Wicket deserializes a Page containing a
> reference
> >>> to
> >>> > a CDI bean, I get this exception:
> >>>
> >>> In what cases exactly ?
> >>> Because the problem is
> >>>
> >>> Caused by: java.lang.ClassNotFoundException:
> >>> org.jboss.msc.service.ServiceName from [Module
> >>> "deployment.wicket.war:main"
> >>> from Service Module Loader]
> >>>
> >>> In what cases this class is no more loadable by the current class
> loader ?
> >>>
> >>> >
> >>> > 15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack]
> >>> > (http--127.0.0.1-8080-1) Error detaching RequestHandler:
> >>> > java.lang.RuntimeException: Could not deserialize object using: class
> >>> >
> >>>
> org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream
> >>> > at
> >>> >
> >>>
> org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137)
> >>> > [wicket-core-1.5.5.jar:1.5.5]
> >>> > at
> >>> >
> >>>
> org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388)
> >>> > [wicket-core-1.5.5.jar:1.5.5]
> >>> > at
> >>> >
> >>>
> org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127)
> >>> > [wicket-core-1.5.5.jar:1.5.5]
> >>> > at
> >>> >
> >>>
> org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192)
> >>> > [wicket-core-1.5.5.jar:1.5.5]
> >>> > at
> >>> >
> >>>
> org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327)
> >>> > [wicket-core-1.5.5.jar:1.5.5]
> >>> > at
> >>> >
> >>>
> org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102)
> >>> > [wicket-core-1.5.5.jar:1.5.5]
> >>> > at
> >>> >
> >>>
> org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50)
> >>> > [wicket-core-1.5.5.jar:1.5.5]
> >>> > at
> >>> >
> >>>
> org.apache.wicket.page.PageAccessSynchronize
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
I'm not familiar with the Wicketopia source, but doing a quick scan I can't find any EJBs in there. The problem in this case occurs if the FooStateless class is @Stateless. Changing this to @ApplicationScoped, the problem goes away. On Thu, Apr 12, 2012 at 8:28 AM, Jonathan Tougas wrote: > A stateless bean is injected into the home page class. Load the page in > two tabs (so twice in the same session), then on the first tab, press the > button. The error occurs every time in this scenario. > > On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov wrote: > >> Hi, >> >> On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas >> wrote: >> > I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to the >> mix. >> > In certain cases when Wicket deserializes a Page containing a reference >> to >> > a CDI bean, I get this exception: >> >> In what cases exactly ? >> Because the problem is >> >> Caused by: java.lang.ClassNotFoundException: >> org.jboss.msc.service.ServiceName from [Module >> "deployment.wicket.war:main" >> from Service Module Loader] >> >> In what cases this class is no more loadable by the current class loader ? >> >> > >> > 15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack] >> > (http--127.0.0.1-8080-1) Error detaching RequestHandler: >> > java.lang.RuntimeException: Could not deserialize object using: class >> > >> org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream >> > at >> > >> org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.handler.PageProvider.getPageParameters(PageProvider.java:184) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.handler.logger.PageLogData.(PageLogData.java:51) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.(ListenerInterfaceLogData.java:56) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.detach(ListenerInterfaceRequestHandler.java:134) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:792) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180) >> > [wicket-request-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:596) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539) >> > [wicket-core-1.5.5.jar:1.5.5] >> > at >> > >> org.apache.wicket.request.cycle.Req
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
A stateless bean is injected into the home page class. Load the page in two tabs (so twice in the same session), then on the first tab, press the button. The error occurs every time in this scenario. On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov wrote: > Hi, > > On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas > wrote: > > I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to the mix. > > In certain cases when Wicket deserializes a Page containing a reference > to > > a CDI bean, I get this exception: > > In what cases exactly ? > Because the problem is > > Caused by: java.lang.ClassNotFoundException: > org.jboss.msc.service.ServiceName from [Module "deployment.wicket.war:main" > from Service Module Loader] > > In what cases this class is no more loadable by the current class loader ? > > > > > 15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack] > > (http--127.0.0.1-8080-1) Error detaching RequestHandler: > > java.lang.RuntimeException: Could not deserialize object using: class > > > org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream > > at > > > org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.PageProvider.getPageParameters(PageProvider.java:184) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.logger.PageLogData.(PageLogData.java:51) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.(ListenerInterfaceLogData.java:56) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.detach(ListenerInterfaceRequestHandler.java:134) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:792) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180) > > [wicket-request-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:596) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:287) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:185) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:241) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) > > [jbossweb-7.0.10.Final.jar:] > > at > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) > > [jbossweb-7.0.10.Final.jar:] > > at > > > org.apache.catalina
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
Using wicket-cdi <https://github.com/42Lines/wicket-cdi> the problem still exists. I'll update the example in a moment. On Wed, Apr 11, 2012 at 3:58 PM, James Carman wrote: > I would recommend checking out one of the existing libraries that does > Wicket/CDI integration. > > On Wed, Apr 11, 2012 at 3:54 PM, Jonathan Tougas > wrote: > > I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to the mix. > > In certain cases when Wicket deserializes a Page containing a reference > to > > a CDI bean, I get this exception: > > > > 15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack] > > (http--127.0.0.1-8080-1) Error detaching RequestHandler: > > java.lang.RuntimeException: Could not deserialize object using: class > > > org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream > > at > > > org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.PageProvider.getPageParameters(PageProvider.java:184) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.logger.PageLogData.(PageLogData.java:51) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.(ListenerInterfaceLogData.java:56) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.detach(ListenerInterfaceRequestHandler.java:134) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:792) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180) > > [wicket-request-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:596) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:287) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:185) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:241) > > [wicket-core-1.5.5.jar:1.5.5] > > at > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) > > [jbossweb-7.0.10.Final.jar:] > > at > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) > > [jbossweb-7.0.10.Final.jar:] > > at > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) > > [jbossweb-7.0.10.Final.jar:] > > at > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) > > [jbossweb-7.0.10.Final.jar:] > > at > > > org.jboss.as
Re: AbstractPageableView cachedItemCount
I see your point, the order the components are rendered is important.
I didn't have any trouble getting this to work though: I have a
UserListPage, which has a SizeLabel (whose getModel() =
datatable.getgetItemCount()), and a UserDataTable. The UserListPage listens
for ajax events to add the SizeLabel to AjaxRequestTarget when appropriate.
The components in the AjaxRequestTarget are ordered, and the datatable is
added first since it is the target of the ajax request, so it's
onBeforeRender is called before the label's. The label then correctly picks
up the new size. This case works, more involves ones might not...
So the deeper reason why the rendering order is important is that the
datatable's model is refreshed as a consequence of rendering. It should
probably be done before the rendering even starts, either as part of the
page load, or a click handler. This way, when the rendering phase comes
around, the data is available, and not dependent on the rendering order of
the components.
If ever I run into the problem where the rendering order is problematic
I'll probably try writing up a datatable that can be explicitly refreshed
like this. For now I'm good :)
Thanks for the help! (and Igor thank you for replying to so many user
questions!)
On Thu, Feb 16, 2012 at 12:26 PM, Igor Vaynberg wrote:
> suppose you have a label before the data table that shows how many
> items are in the table. it uses datatable.getitemcount() to do this.
>
> onbeforerender() will be called on the label before it is on the
> datatable so it now uses the stale item count and is out of sync with
> the datatable.
>
> -igor
>
> On Thu, Feb 16, 2012 at 9:08 AM, Jonathan Tougas
> wrote:
> > It should be discarded only before rendering.
> >
> > I figured out a way to accomplish this by extending the DataTable class
> > and creating a wrapper for the data provider with a cache of it's own,
> > which bypasses the AbstractPageableView's size cache. This one is cleared
> > by the extension of DataTable before rendering like I'm suggesting:
> >
> > public class SuperTable extends DataTable {
> >
> > private SuperDataProviderWrapper dataProviderWrapper;
> > public SuperTable( String id, List> columns,
> > SuperDataProviderWrapper dataProviderWrapper, int rowsPerPage ) {
> > super( id, columns, dataProviderWrapper, rowsPerPage );
> > this.dataProviderWrapper = dataProviderWrapper;
> > setOutputMarkupId( true );
> > setVersioned( false );
> > addTopToolbar( new AjaxNavigationToolbar( this ) );
> > addTopToolbar( new AjaxFallbackHeadersToolbar( this,
> dataProviderWrapper )
> > );
> > addBottomToolbar( new NoRecordsToolbar( this ) );
> > }
> >
> > @Override
> > protected Item newRowItem( final String id, final int index, final
> > IModel model ) {
> > return new OddEvenItem( id, index, model );
> > }
> > @Override
> > protected void onBeforeRender() {
> > // reset size before rendering!
> > dataProviderWrapper.resetSize();
> > super.onBeforeRender();
> > }
> > }
> >
> > public class SuperDataProviderWrapper implements
> > ISortableDataProvider {
> >
> > private ISortableDataProvider delegate;
> > private int size;
> > public SuperDataProviderWrapper( ISortableDataProvider delegate ) {
> > this.delegate = delegate;
> > resetSize();
> > }
> >
> > @Override
> > public int size() {
> > if( size == -1 ) {
> > size = delegate.size();
> > }
> > return size;
> > }
> >
> > public void resetSize() {
> > size = -1;
> > }
> >/*snip delegations...*/
> > }
> >
> > End result is one call to count when the ajax links are clicked instead
> of
> > two.
> >
> > On Wed, Feb 15, 2012 at 7:33 PM, Igor Vaynberg >wrote:
> >
> >> so when should it be discarded?
> >>
> >> -igor
> >>
> >> On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas
> >> wrote:
> >> > The cachedItemCount calculated in onBeforeRender should not be
> discarded
> >> at
> >> > the end of a request (so the clear in onDetach and readObject
> shouldn't
> >> be
> >> > there). This way it would still be around when a request comes in to
> >> handle
> >> > a click.
> >> >
> >> > On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff
> >> wrote:
> >> >
> >> >> Thanks for the clarification. I see your point now: if records are
> >> deleted
> >> >> from the database, the navigation click is ignored an t
Re: AbstractPageableView cachedItemCount
It should be discarded only before rendering.
I figured out a way to accomplish this by extending the DataTable class
and creating a wrapper for the data provider with a cache of it's own,
which bypasses the AbstractPageableView's size cache. This one is cleared
by the extension of DataTable before rendering like I'm suggesting:
public class SuperTable extends DataTable {
private SuperDataProviderWrapper dataProviderWrapper;
public SuperTable( String id, List> columns,
SuperDataProviderWrapper dataProviderWrapper, int rowsPerPage ) {
super( id, columns, dataProviderWrapper, rowsPerPage );
this.dataProviderWrapper = dataProviderWrapper;
setOutputMarkupId( true );
setVersioned( false );
addTopToolbar( new AjaxNavigationToolbar( this ) );
addTopToolbar( new AjaxFallbackHeadersToolbar( this, dataProviderWrapper )
);
addBottomToolbar( new NoRecordsToolbar( this ) );
}
@Override
protected Item newRowItem( final String id, final int index, final
IModel model ) {
return new OddEvenItem( id, index, model );
}
@Override
protected void onBeforeRender() {
// reset size before rendering!
dataProviderWrapper.resetSize();
super.onBeforeRender();
}
}
public class SuperDataProviderWrapper implements
ISortableDataProvider {
private ISortableDataProvider delegate;
private int size;
public SuperDataProviderWrapper( ISortableDataProvider delegate ) {
this.delegate = delegate;
resetSize();
}
@Override
public int size() {
if( size == -1 ) {
size = delegate.size();
}
return size;
}
public void resetSize() {
size = -1;
}
/*snip delegations...*/
}
End result is one call to count when the ajax links are clicked instead of
two.
On Wed, Feb 15, 2012 at 7:33 PM, Igor Vaynberg wrote:
> so when should it be discarded?
>
> -igor
>
> On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas
> wrote:
> > The cachedItemCount calculated in onBeforeRender should not be discarded
> at
> > the end of a request (so the clear in onDetach and readObject shouldn't
> be
> > there). This way it would still be around when a request comes in to
> handle
> > a click.
> >
> > On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff
> wrote:
> >
> >> Thanks for the clarification. I see your point now: if records are
> deleted
> >> from the database, the navigation click is ignored an the page is simply
> >> re-rendered. But if the data content has changed such that the
> navigation
> >> no longer makes sense, what behavior would you prefer?
> >>
> >> On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas
> >> wrote:
> >>
> >> > The PagingNavigationIncrementLink's linksTo(Page), which calls
> isLast()
> >> > which calls pageable getPageCount() which ends up calling size()
> >> > eventually. This is called during Component.canCallListenerInterface
> >> > (*you're
> >> > right it's not isVisible*) to verify if the link can indeed be
> clicked.
> >> >
> >> > And to be clear I am discussing multiple size() calls in one request.
> It
> >> > happens when clicking on the navigation links: size() is called first
> as
> >> > part of the verifying if the link is enabled (as described above),
> then
> >> the
> >> > cached value is discarded just before rendering (in onBeforeRender()).
> >> Then
> >> > size() is called again as part of the rendering, and again cached. The
> >> > cached value is again discarded at the end of the request in
> onDetach().
> >> > What I'm saying is the the first size() shouldn't occur because the
> page
> >> > count should be cached from the previous rendering (it shouldn't be
> >> cleared
> >> > in onDetach() nor readObject()).
> >> >
> >> > On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff
> >> wrote:
> >> >
> >> > > Hi, Jonathan. Which component are you referring to? I don't see
> >> > isVisible()
> >> > > overrides in PagingNavigator or its helpers.
> >> > >
> >> > >
> >> > > > It's state and as such should not be discarded when
> >> > > > the request is finished, it's still needed for things like
> checking
> >> if
> >> > a
> >> > > > link was indeed visible when a click comes in for it.
> >> > >
> >> > >
> >> > > How can you receive a click event for a link that was not visible?
> >> > > Invisible components aren't rendered.
> >> > >
> >> > > That JIRA discusses multiple size() calls in a single reques
Re: AbstractPageableView cachedItemCount
The cachedItemCount calculated in onBeforeRender should not be discarded at the end of a request (so the clear in onDetach and readObject shouldn't be there). This way it would still be around when a request comes in to handle a click. On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff wrote: > Thanks for the clarification. I see your point now: if records are deleted > from the database, the navigation click is ignored an the page is simply > re-rendered. But if the data content has changed such that the navigation > no longer makes sense, what behavior would you prefer? > > On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas > wrote: > > > The PagingNavigationIncrementLink's linksTo(Page), which calls isLast() > > which calls pageable getPageCount() which ends up calling size() > > eventually. This is called during Component.canCallListenerInterface > > (*you're > > right it's not isVisible*) to verify if the link can indeed be clicked. > > > > And to be clear I am discussing multiple size() calls in one request. It > > happens when clicking on the navigation links: size() is called first as > > part of the verifying if the link is enabled (as described above), then > the > > cached value is discarded just before rendering (in onBeforeRender()). > Then > > size() is called again as part of the rendering, and again cached. The > > cached value is again discarded at the end of the request in onDetach(). > > What I'm saying is the the first size() shouldn't occur because the page > > count should be cached from the previous rendering (it shouldn't be > cleared > > in onDetach() nor readObject()). > > > > On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff > wrote: > > > > > Hi, Jonathan. Which component are you referring to? I don't see > > isVisible() > > > overrides in PagingNavigator or its helpers. > > > > > > > > > > It's state and as such should not be discarded when > > > > the request is finished, it's still needed for things like checking > if > > a > > > > link was indeed visible when a click comes in for it. > > > > > > > > > How can you receive a click event for a link that was not visible? > > > Invisible components aren't rendered. > > > > > > That JIRA discusses multiple size() calls in a single request. You're > > > discussing multiple size() calls with multiple requests. Right? > > > > > > Dan > > > > > > On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas > > > wrote: > > > > > > > I noticed two count queries go by when using the DataTable component. > > so > > > I > > > > searched and dug up this jira issue > > > > https://issues.apache.org/jira/browse/WICKET-1766 which is a "won't > > > fix". > > > > > > > > Igor states that two queries are required each request, but I see > this > > > > differently: > > > > > > > > The count is a used as the basis for the paging navigator's > > isVisible(), > > > so > > > > far so good. The issue is that the count is discarded in onDetach() > (as > > > > well as readObject()). It's state and as such should not be discarded > > > when > > > > the request is finished, it's still needed for things like checking > if > > a > > > > link was indeed visible when a click comes in for it. If it's not > > kept, a > > > > new query to the model will be made, which might return a different > > > result > > > > - consequences ensue. The critical part of that is we are checking if > > the > > > > link *was* visible, not if it *is* visible. > > > > > > > > I think the only time it should be discarded is in the > onBeforeRender() > > > > event. This is when we are actually interested in going back to the > > model > > > > to see if the value has changed. So to me this is indeed a bug. I > don't > > > > mind patching something up myself, or reopening the ticket...but I > > would > > > > like a confirmation that I'm not way out in left field ;) > > > > > > > > Cheers! > > > > Jonathan Tougas > > > > > > > > > >
Re: AbstractPageableView cachedItemCount
The PagingNavigationIncrementLink's linksTo(Page), which calls isLast() which calls pageable getPageCount() which ends up calling size() eventually. This is called during Component.canCallListenerInterface (*you're right it's not isVisible*) to verify if the link can indeed be clicked. And to be clear I am discussing multiple size() calls in one request. It happens when clicking on the navigation links: size() is called first as part of the verifying if the link is enabled (as described above), then the cached value is discarded just before rendering (in onBeforeRender()). Then size() is called again as part of the rendering, and again cached. The cached value is again discarded at the end of the request in onDetach(). What I'm saying is the the first size() shouldn't occur because the page count should be cached from the previous rendering (it shouldn't be cleared in onDetach() nor readObject()). On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff wrote: > Hi, Jonathan. Which component are you referring to? I don't see isVisible() > overrides in PagingNavigator or its helpers. > > > > It's state and as such should not be discarded when > > the request is finished, it's still needed for things like checking if a > > link was indeed visible when a click comes in for it. > > > How can you receive a click event for a link that was not visible? > Invisible components aren't rendered. > > That JIRA discusses multiple size() calls in a single request. You're > discussing multiple size() calls with multiple requests. Right? > > Dan > > On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas > wrote: > > > I noticed two count queries go by when using the DataTable component. so > I > > searched and dug up this jira issue > > https://issues.apache.org/jira/browse/WICKET-1766 which is a "won't > fix". > > > > Igor states that two queries are required each request, but I see this > > differently: > > > > The count is a used as the basis for the paging navigator's isVisible(), > so > > far so good. The issue is that the count is discarded in onDetach() (as > > well as readObject()). It's state and as such should not be discarded > when > > the request is finished, it's still needed for things like checking if a > > link was indeed visible when a click comes in for it. If it's not kept, a > > new query to the model will be made, which might return a different > result > > - consequences ensue. The critical part of that is we are checking if the > > link *was* visible, not if it *is* visible. > > > > I think the only time it should be discarded is in the onBeforeRender() > > event. This is when we are actually interested in going back to the model > > to see if the value has changed. So to me this is indeed a bug. I don't > > mind patching something up myself, or reopening the ticket...but I would > > like a confirmation that I'm not way out in left field ;) > > > > Cheers! > > Jonathan Tougas > > >
AbstractPageableView cachedItemCount
I noticed two count queries go by when using the DataTable component. so I searched and dug up this jira issue https://issues.apache.org/jira/browse/WICKET-1766 which is a "won't fix". Igor states that two queries are required each request, but I see this differently: The count is a used as the basis for the paging navigator's isVisible(), so far so good. The issue is that the count is discarded in onDetach() (as well as readObject()). It's state and as such should not be discarded when the request is finished, it's still needed for things like checking if a link was indeed visible when a click comes in for it. If it's not kept, a new query to the model will be made, which might return a different result - consequences ensue. The critical part of that is we are checking if the link *was* visible, not if it *is* visible. I think the only time it should be discarded is in the onBeforeRender() event. This is when we are actually interested in going back to the model to see if the value has changed. So to me this is indeed a bug. I don't mind patching something up myself, or reopening the ticket...but I would like a confirmation that I'm not way out in left field ;) Cheers! Jonathan Tougas
Re: refresh and AjaxFallbackDefaultDataTable
> > Can't you fix that with a > getPage().dirty(); > in the Ajax request handler? Hmm tried your suggestion, but no luck. How would it help anyway? It's dirty() that is causing the page to change version in the first place right? RefreshingView.onPopulate() -> MarkupContainer.removeAll() -> Component.addStateChange() -> Page.componentStateChanging() -> Page.dirty() -> new version number! I did find a fix for this though. Changing the rendering strategy from the default REDIRECT_TO_BUFFER to ONE_PASS_RENDER. With this strategy, the initial request is not redirect to "*?%version%*", which means when the user presses refresh, a new page is recreated from scratch every time. Ajax updates are applied on the version of the page that originally rendered them, so there's no ambiguity like the scenario I describe. The drawback of course is that page refreshes lose ajax updates, but the semantic in that case at least is very clear and it's what I expected in the first place. On Tue, Feb 14, 2012 at 7:32 AM, Wilhelmsen Tor Iver wrote: > > Thus the browser still shows the old version in the URL. But all future > Ajax requests are targetting a different page version than visible in the > browser URL :(. > > Can't you fix that with a > > getPage().dirty(); > > in the Ajax request handler? > > - Tor Iver > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
refresh and AjaxFallbackDefaultDataTable
I'm getting some inconsistent behavior with AjaxFallbackDefaultDataTable. Here are two scenarios that can be run on wicket-examples: *Scenario 1* 1 - navigate to http://wicketstuff.org/wicket/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.AjaxDataTablePage 2 - click the link to navigate to page 2 3 - refresh (F5) After the page refresh, you're still on page 2 - as expected *Scenario 2:* 1 - navigate to http://wicketstuff.org/wicket/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.AjaxDataTablePage 2 - refresh (F5) 3 - click the link to navigate to results page 2 4 - refresh (F5) After the page refresh you're back to page 1 - oops The navigation links work fine until the page is refreshed. After a page refresh the navigation links point to the wrong page version (or so it seems), so refreshing a second time doesn't work as expected. I'm fairly new to Wicket so I may be missing something, and I haven't found a bug report for this. Can someone confirm or explain what I"m not getting please? Cheers!
