date:20160219

Quesitont about .repeater.DataTableFilterToolbarPage : mutliple fitered

2016-02-19 Thread andre seame

Hello,


The repeater.DataTableFilterToolpage 

 demonstrates a unique filter.


My questions are :

- Is it possible to have several sortable columns.

- How to put the 2 sortable fields into the th ? Or Foreach sortable column, I 
would like to add the 2 fields in the associated column.


For instance:


 
   Born datefrom: ...
   Death Datefrom: ...



Thanks,

PHL.

Re: Wicketstuff editable grid - 7.1.0

2016-02-19 Thread Mihir Chhaya

Ok, so creating a small project with two panels(Person and Customer) and a
page for similar use case resulted in following stacktrace.
The panels are added in the order of PersonPanel, CustomerPanel in the
parent page.

The line# 163 in onSave method of EditableGrid is calling
EditableGrid.this.onSave(target, rowModel); I wonder if the reference to
this is referring to the first EditableGrid with Person records. Switching
the order of adding grid panels throws the error other way around;
complaining for Person cannot be cast to Customer.

*java.lang.ClassCastException: spikes.domain.Customer cannot be cast
to spikes.domain.Person*
 at spikes.view.PersonPanel$1.onSave(PersonPanel.java:68)
 at org.wicketstuff.egrid.EditableGrid$3.onSave(EditableGrid.java:163)
 at 
org.wicketstuff.egrid.column.EditableGridActionsColumn$1.onSave(EditableGridActionsColumn.java:34)
 at 
org.wicketstuff.egrid.column.EditableGridActionsPanel$2.onSuccess(EditableGridActionsPanel.java:71)
 at 
org.wicketstuff.egrid.component.EditableGridSubmitLink.onSubmit(EditableGridSubmitLink.java:37)
 at 
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:110)
 at 
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior$AjaxFormSubmitter.onSubmit(AjaxFormSubmitBehavior.java:215)
 at org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1307)
 at 
org.wicketstuff.egrid.EditableGrid$NonValidatingForm.process(EditableGrid.java:79)
 at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:795)
 at 
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:171)
 at 
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:155)
 at 
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:588)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerInterface.java:258)
 at 
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:241)
 at 
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
 at 
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
 at 
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
 at 
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
 at 
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
 at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
 at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
 at 
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
 at 
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
 at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
 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.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
 at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
 at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
 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:312)
 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:744)

Complete stack:

org.apache.wicket.WicketRuntimeException: Method onRequest of
interface org.apache.wicket.behavior.IBehaviorListener targeted at
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1@47743d65 on
component [EditableGridSubmitLink [Component id = save]] threw an
exception
 at 
org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerInterface.java:268)
 at

Re: Wicket model problem

2016-02-19 Thread Francois Meillet

You can also use a IDetachListener to check that no one LDM (field) is attached 
after the page#detach() has been called. 

In the Application#init() you can add

getFrameworkSettings().setDetachListener(

new IDetachListener() {

@Override
public void onDetach(Component component) {

for (Field field : 
component.getClass().getDeclaredFields()) {
field.setAccessible(true);

Class theClass = field.getType();
if 
(LoadableDetachableModel.class.isAssignableFrom(theClass)) {

try {
if (((LoadableDetachableModel) 
field.get(component)).isAttached()) {
System.err.println("warning: component:" + 
component.getClass().getName() + " / " + field.getName() + " is attached");
}
}
//
catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}
}

@Override
public void onDestroyListener() {

}
}
);


François 








Le 19 févr. 2016 à 16:47, Bas Gooren  a écrit :

> Hi,
> 
> I think the only way to track this is with custom code (or with aspects for 
> example).
> 
> Since the contract of IModel only has detach() (and not isDetached()), this 
> cannot be tracked easily.
> 
> What I would do in such a case is probably to add a requestcyclelistener 
> which walks a page after a request, iterates (/visits) over all the 
> components and checks their models.
> Of course this requires the models to expose a way to check their status and 
> origin.
> 
> Also, what we do to prevent this: we have an abstract base model called a 
> AbstractConversionModel which takes a parent model (S) and converts to a 
> target type (T), caching the conversion.
> This model takes a parent model as input (and subclasses of it require a java 
> 8 Function or expose an abstract method for the conversion etc).
> This model also takes care of detaching the parent model.
> 
> In the end it’s all about education I guess: programmer’s should be careful 
> when chaining models and ensure they detach the parent (/chained) model.
> 
> Met vriendelijke groet,
> Kind regards,
> 
> Bas
> 
> Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com) 
> schreef:
> 
> Thanks for the reply. I suspect this is exactly the case we have created for  
> ourselves. Although we have a good grasp on the detach process I suspect  
> that there are places where this rule of thumb is not being followed.  
> Although the example I gave is somewhat fictitious, any of the LDMs we have  
> in our framework perform a detach on the parent. In the form there are  
> numerous places where adhoc anonymous models are created and this is  
> probably where the problems occur. Is there a recommended way to track  
> these down? I ended up recompiling a version of Wicket with changes to  
> LoadableDetachableModel that would essentially track every LDM within a  
> RequestCycle. At the end of a request cycle I was left with a list of the  
> models that never got detached. I also added a "whereAmI" member variable  
> to LDM that would capture the stack trace in the constructor so I could  
> figure out who instantiated the model in the first place.  
> 
> --  
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.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: Wicketstuff editable grid - 7.1.0

2016-02-19 Thread Mihir Chhaya

Just realized that last two lines could be confusing: the decisionCode is
the property of class PcaCodes in pcapanel, but showing up for exccodepanel
row item.

On Fri, Feb 19, 2016 at 12:06 PM, Mihir Chhaya 
wrote:

> My mistake about the inmethod grid dependency. I don't know why I saw
> compilation error in editable grid class when removed inmethod grid jar
> from classpath.
>
> For debugging the respond method as your suggestion, I do see correct
> class types for each rowItem (as attachment). But it fails with following
> error:
>
> Last cause: No get method defined for class: class
> packagename.ExceptionalDocCode expression: decisionCode
> WicketMessage: Exception in rendering component:
> [EditableTextFieldCellPanel [Component id = cell]]
>
>
> On Thu, Feb 18, 2016 at 5:06 PM, Martin Grigorov 
> wrote:
>
>> On Thu, Feb 18, 2016 at 10:53 PM, Mihir Chhaya 
>> wrote:
>>
>> > Thanks, Martin.
>> >
>> > By writing dependency on wicket in-method grid I meant editable grid
>> > inherently referring inmethod grid.
>> >
>>
>>
>> https://github.com/wicketstuff/core/blob/master/editable-grid-parent/editable-grid/pom.xml
>>
>> https://github.com/wicketstuff/core/blob/master/editable-grid-parent/pom.xml
>> The only dependency is wicket-extensions.
>> I am not sure what you mean by "inherently referring".
>>
>>
>> >
>> > I did check the Ajax url earlier and following are the values in
>> rendered
>> > html page for the panel.
>> >
>> >
>> >
>> Wicket.Ajax.ajax({"u":"./appcontext?5-2.IBehaviorListener.0-admincontroltabs-panel-pcapanel-pcacodegridForm-pcaDataTable-form-dataTable-body-rows-16-cells-6-cell-edit","c":"edit104","e":"click"});;
>> >
>> >
>> >
>> Wicket.Ajax.ajax({"u":"./appcontext?5-2.IBehaviorListener.0-admincontroltabs-panel-exccodepanel-excdoccodegridForm-excDataTable-form-dataTable-body-rows-10-cells-4-cell-edit","c":"edit113","e":"click"});;
>> >
>>
>> Assuming that 'pcapanel' is 'aPanel' and 'exccodepanel' is 'bPanel'
>> everything looks OK.
>> Clicking on any of those cells should correctly find the respective grid
>> cell and execute its Ajax behavior.
>> Put a breakpoint in AjaxEventBehavior#respond() and see why it finds
>> ClassB.
>>
>>
>> >
>> > Thanks,
>> > -Mihir.
>> >
>> > On Thu, Feb 18, 2016 at 3:18 PM, Martin Grigorov 
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > On Wed, Feb 17, 2016 at 5:09 PM, Mihir Chhaya > >
>> > > wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > My apologies if this is not the right place to post wicketstuff
>> related
>> > > > issues. If so, then please advice me with right forum/link.
>> > > >
>> > >
>> > > This is the right forum!
>> > >
>> > >
>> > > >
>> > > > I am using Wicketstuff-editable-grid-7.1.0 (with dependency on
>> > > > wicketstuff-inmethod-grid-7.1.0).
>> > > >
>> > >
>> > > Why InMethod-Grid is needed? Or you are migrating from Inmethod to
>> > Editable
>> > > ?
>> > >
>> > >
>> > > >
>> > > > *Problem:*
>> > > > When two editable grids from two separate child panels are rendered
>> > into
>> > > > single container (parent panel), then clicking 'Edit' link in the
>> row
>> > for
>> > > > ClassA related editable grid throws 'No get method defined for the
>> > class'
>> > > > error for ClassB property which is related to another editable grid.
>> > > >
>> > >
>> > > Check what is the url for the Ajax call that is made.
>> > > This should tell you why it finds ClassB instead of ClassA.
>> > >
>> > >
>> > > >
>> > > > *Requirement:*
>> > > > I have a page with 4 different tabs. On one of the tabs, I want to
>> use
>> > a
>> > > > panel with two editable grids for two different static dataset
>> Add/Edit
>> > > > (One grid for tableA, another for tableB).
>> > > >
>> > > > *Efforts:*
>> > > > I have created two separate panel classes as below - each with it's
>> own
>> > > > form and editable grid with it's own editable data provider with
>> > > respective
>> > > > array list of different types. The columns supplied to EditableGrid
>> > class
>> > > > contains
>> > > > EditableTextFieldPropertyColumn and 
>> > > > respectively with own properties. Please note that I have used
>> distinct
>> > > > markup Ids for each panel and grid components to avoid any
>> duplication;
>> > > > with setting output markup id to true.
>> > > >
>> > > > PanelA extends Panel{
>> > > >
>> > > > //Constructor
>> > > > // formA with editableGridA with editableDataProviderForClassA
>> > > > }
>> > > >
>> > > > PanelB extends Panel{
>> > > >
>> > > > //Constructor
>> > > > //formB with editableGridB with editableDataProviderForClassB
>> using
>> > > > }
>> > > >
>> > > > Those two panels are added into parent panel as below:
>> > > >
>> > > > TabbedPanel extends Panel{
>> > > >
>> > > >  //Constructor
>> > > >  // Panel panelA = new PanelA("aPanel");
>> > > >  // Panel panelB = new PanelB("bPanel");
>> >

Re: Wicketstuff editable grid - 7.1.0

2016-02-19 Thread Mihir Chhaya

My mistake about the inmethod grid dependency. I don't know why I saw
compilation error in editable grid class when removed inmethod grid jar
from classpath.

For debugging the respond method as your suggestion, I do see correct class
types for each rowItem (as attachment). But it fails with following error:

Last cause: No get method defined for class: class
packagename.ExceptionalDocCode expression: decisionCode
WicketMessage: Exception in rendering component:
[EditableTextFieldCellPanel [Component id = cell]]


On Thu, Feb 18, 2016 at 5:06 PM, Martin Grigorov 
wrote:

> On Thu, Feb 18, 2016 at 10:53 PM, Mihir Chhaya 
> wrote:
>
> > Thanks, Martin.
> >
> > By writing dependency on wicket in-method grid I meant editable grid
> > inherently referring inmethod grid.
> >
>
>
> https://github.com/wicketstuff/core/blob/master/editable-grid-parent/editable-grid/pom.xml
>
> https://github.com/wicketstuff/core/blob/master/editable-grid-parent/pom.xml
> The only dependency is wicket-extensions.
> I am not sure what you mean by "inherently referring".
>
>
> >
> > I did check the Ajax url earlier and following are the values in rendered
> > html page for the panel.
> >
> >
> >
> Wicket.Ajax.ajax({"u":"./appcontext?5-2.IBehaviorListener.0-admincontroltabs-panel-pcapanel-pcacodegridForm-pcaDataTable-form-dataTable-body-rows-16-cells-6-cell-edit","c":"edit104","e":"click"});;
> >
> >
> >
> Wicket.Ajax.ajax({"u":"./appcontext?5-2.IBehaviorListener.0-admincontroltabs-panel-exccodepanel-excdoccodegridForm-excDataTable-form-dataTable-body-rows-10-cells-4-cell-edit","c":"edit113","e":"click"});;
> >
>
> Assuming that 'pcapanel' is 'aPanel' and 'exccodepanel' is 'bPanel'
> everything looks OK.
> Clicking on any of those cells should correctly find the respective grid
> cell and execute its Ajax behavior.
> Put a breakpoint in AjaxEventBehavior#respond() and see why it finds
> ClassB.
>
>
> >
> > Thanks,
> > -Mihir.
> >
> > On Thu, Feb 18, 2016 at 3:18 PM, Martin Grigorov 
> > wrote:
> >
> > > Hi,
> > >
> > > On Wed, Feb 17, 2016 at 5:09 PM, Mihir Chhaya 
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > My apologies if this is not the right place to post wicketstuff
> related
> > > > issues. If so, then please advice me with right forum/link.
> > > >
> > >
> > > This is the right forum!
> > >
> > >
> > > >
> > > > I am using Wicketstuff-editable-grid-7.1.0 (with dependency on
> > > > wicketstuff-inmethod-grid-7.1.0).
> > > >
> > >
> > > Why InMethod-Grid is needed? Or you are migrating from Inmethod to
> > Editable
> > > ?
> > >
> > >
> > > >
> > > > *Problem:*
> > > > When two editable grids from two separate child panels are rendered
> > into
> > > > single container (parent panel), then clicking 'Edit' link in the row
> > for
> > > > ClassA related editable grid throws 'No get method defined for the
> > class'
> > > > error for ClassB property which is related to another editable grid.
> > > >
> > >
> > > Check what is the url for the Ajax call that is made.
> > > This should tell you why it finds ClassB instead of ClassA.
> > >
> > >
> > > >
> > > > *Requirement:*
> > > > I have a page with 4 different tabs. On one of the tabs, I want to
> use
> > a
> > > > panel with two editable grids for two different static dataset
> Add/Edit
> > > > (One grid for tableA, another for tableB).
> > > >
> > > > *Efforts:*
> > > > I have created two separate panel classes as below - each with it's
> own
> > > > form and editable grid with it's own editable data provider with
> > > respective
> > > > array list of different types. The columns supplied to EditableGrid
> > class
> > > > contains
> > > > EditableTextFieldPropertyColumn and 
> > > > respectively with own properties. Please note that I have used
> distinct
> > > > markup Ids for each panel and grid components to avoid any
> duplication;
> > > > with setting output markup id to true.
> > > >
> > > > PanelA extends Panel{
> > > >
> > > > //Constructor
> > > > // formA with editableGridA with editableDataProviderForClassA
> > > > }
> > > >
> > > > PanelB extends Panel{
> > > >
> > > > //Constructor
> > > > //formB with editableGridB with editableDataProviderForClassB
> using
> > > > }
> > > >
> > > > Those two panels are added into parent panel as below:
> > > >
> > > > TabbedPanel extends Panel{
> > > >
> > > >  //Constructor
> > > >  // Panel panelA = new PanelA("aPanel");
> > > >  // Panel panelB = new PanelB("bPanel");
> > > >  // add(panelA); add(panelB);
> > > > }
> > > >
> > > > As I have mentioned in the problem above; clicking on edit link for
> > > classA
> > > > related grid is throwing error for classB property, which is
> associated
> > > > with different editable grid.
> > > >
> > > > Has anybody experienced similar issue? Any help/suggestions?
> > > >
> > >
> > > Everything looks OK.
> > > Check whether the url

Re: Wicket model problem

2016-02-19 Thread Francois Meillet

see the LoadableDetachableModel # isAttached() method which return the attached 
status of this model instance 

François 








Le 19 févr. 2016 à 16:47, Bas Gooren  a écrit :

> Hi,
> 
> I think the only way to track this is with custom code (or with aspects for 
> example).
> 
> Since the contract of IModel only has detach() (and not isDetached()), this 
> cannot be tracked easily.
> 
> What I would do in such a case is probably to add a requestcyclelistener 
> which walks a page after a request, iterates (/visits) over all the 
> components and checks their models.
> Of course this requires the models to expose a way to check their status and 
> origin.
> 
> Also, what we do to prevent this: we have an abstract base model called a 
> AbstractConversionModel which takes a parent model (S) and converts to a 
> target type (T), caching the conversion.
> This model takes a parent model as input (and subclasses of it require a java 
> 8 Function or expose an abstract method for the conversion etc).
> This model also takes care of detaching the parent model.
> 
> In the end it’s all about education I guess: programmer’s should be careful 
> when chaining models and ensure they detach the parent (/chained) model.
> 
> Met vriendelijke groet,
> Kind regards,
> 
> Bas
> 
> Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com) 
> schreef:
> 
> Thanks for the reply. I suspect this is exactly the case we have created for  
> ourselves. Although we have a good grasp on the detach process I suspect  
> that there are places where this rule of thumb is not being followed.  
> Although the example I gave is somewhat fictitious, any of the LDMs we have  
> in our framework perform a detach on the parent. In the form there are  
> numerous places where adhoc anonymous models are created and this is  
> probably where the problems occur. Is there a recommended way to track  
> these down? I ended up recompiling a version of Wicket with changes to  
> LoadableDetachableModel that would essentially track every LDM within a  
> RequestCycle. At the end of a request cycle I was left with a list of the  
> models that never got detached. I also added a "whereAmI" member variable  
> to LDM that would capture the stack trace in the constructor so I could  
> figure out who instantiated the model in the first place.  
> 
> --  
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.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 model problem

2016-02-19 Thread Bas Gooren

Hi,

I think the only way to track this is with custom code (or with aspects for 
example).

Since the contract of IModel only has detach() (and not isDetached()), this 
cannot be tracked easily.

What I would do in such a case is probably to add a requestcyclelistener which 
walks a page after a request, iterates (/visits) over all the components and 
checks their models.
Of course this requires the models to expose a way to check their status and 
origin.

Also, what we do to prevent this: we have an abstract base model called a 
AbstractConversionModel which takes a parent model (S) and converts to a 
target type (T), caching the conversion.
This model takes a parent model as input (and subclasses of it require a java 8 
Function or expose an abstract method for the conversion etc).
This model also takes care of detaching the parent model.

In the end it’s all about education I guess: programmer’s should be careful 
when chaining models and ensure they detach the parent (/chained) model.

Met vriendelijke groet,
Kind regards,

Bas

Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com) 
schreef:

Thanks for the reply. I suspect this is exactly the case we have created for  
ourselves. Although we have a good grasp on the detach process I suspect  
that there are places where this rule of thumb is not being followed.  
Although the example I gave is somewhat fictitious, any of the LDMs we have  
in our framework perform a detach on the parent. In the form there are  
numerous places where adhoc anonymous models are created and this is  
probably where the problems occur. Is there a recommended way to track  
these down? I ended up recompiling a version of Wicket with changes to  
LoadableDetachableModel that would essentially track every LDM within a  
RequestCycle. At the end of a request cycle I was left with a list of the  
models that never got detached. I also added a "whereAmI" member variable  
to LDM that would capture the stack trace in the constructor so I could  
figure out who instantiated the model in the first place.  

--  
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.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 model problem

2016-02-19 Thread gmparker2000

Thanks for the reply.  I suspect this is exactly the case we have created for
ourselves.  Although we have a good grasp on the detach process I suspect
that there are places where this rule of thumb is not being followed. 
Although the example I gave is somewhat fictitious, any of the LDMs we have
in our framework perform a detach on the parent.  In the form there are
numerous places where adhoc anonymous models are created and this is
probably where the problems occur.  Is there a recommended way to track
these down?  I ended up recompiling a version of Wicket with changes to
LoadableDetachableModel that would essentially track every LDM within a
RequestCycle.  At the end of a request cycle I was left with a list of the
models that never got detached.  I also added a "whereAmI" member variable
to LDM that would capture the stack trace in the constructor so I could
figure out who instantiated the model in the first place.  

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.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 model problem

2016-02-19 Thread Bas Gooren

Hi!

Perhaps this is stating the obvious since it looks like you know what you are 
doing, but just to be sure:

Does your LoadableDetachableExpressionModel call detach on its “parent” model? 
This is the most frequently occurring source of model leaks I have seen.
Since the last model in the chain is usually attached to a component, that 
model gets detached, but if your “child” model does not call detach on the 
“parent” model and the “parent” model is not attached to a component, it will 
never get detached.

Which model in your example is not getting detached without your override of 
onDetach() in MyPanel? Does it happen to be “abc”?

Met vriendelijke groet,
Kind regards,

Bas

Op 19 februari 2016 bij 15:18:41, gmparker2000 (greg.par...@brovada.com) 
schreef:

It's hard to give specifics as the form is very complex. I do have a general  
example of a pattern prevalent throughout the form. The pseudo code goes  
something like this:  

// Page  
class MyPage extends Page {  
onInitialize() {  
Panel p = PanelFactory.createPanel("myPanel", "myObject");  
this.add(p);  
}  
}  

// Factory for creating panels that use a document cache based loadable  
detachable  
// model  
class PanelFactory {  
Panel createPanel(String panelName, String cachedObjectName) {  
// uses the document name to retrieve doc from the cache using it's  
name  
DocumentCacheLDM ldm = new DocumentCacheLDM(cachedObjectName);  

// return a panel initialized with the model  
if ("myPanel".equals(panelName)) {  
return new MyPanel(ldm);  
}  

  
}  
}  

// Panel  
class MyPanel extends Panel {  

MyPanel(final IModel cacheLDM) {  

// create an LDM that uses the cache LDM and an expression. Note  
that it is marked final  
// so it can be used in the list panel below  
final LoadableDetachableModel abc = new  
LoadableDetachableExpressionModel(cacheLDM, "a.b.c");  

// another one based on abc  
LoadableDetachableModel def = new  
LoadableDetachableExpressionModel(abc, "d.e.f");  

// create a panel for DEF object  
Panel subPanel = new SubPanel(def);  
this.add(subPanel);  

// create a model for a repeating list of GHI  
LoadableDetachableModel ghi = new  
LoadableDetachableExpressionModel(abc, "g.h.i");  

// create a repeating section for GHIs  
ListPanel listPanel = new ListPanel("listPanel", ghi) {  
@Override  
public Component createItemComponent(String id, IModel  
model, Item item) {  
return new GHIPanel(id, model, isReadonly, mode);  
}  

@Override  
public void addItem(AjaxRequestTarget target) {  
// uses abc model from above to add the new GHI  
abc.getObject().addNewGHI();  
}  

@Override  
public IModel getItemModel(GHI item) {  
// create an LDM for the GHI item that might use the items's  
id internally  
// to load  
return new LoadableDetachableExpressionModel(abc, item);  
}  

@Override  
public void removeItem(GHI item, AjaxRequestTarget target) {  
abc.getObject().deleteGHI(item);  
}  
}  

this.add(listPanel);  
}  
}  


This pattern, in our case, seems to end with a bunch of models that never  
get detached. Therefore on subsequent request we end up with some parts of  
the form reattached to the document from the cache and other parts attached  
to orphaned transient models from their unattached models. Then when you  
submit the form the components that are attached to the cached object update  
the correct model object but the ones that didn't get detached properly  
update the orphaned model objects. So we end up with data lose. To get  
this working we changed the MyPanel class to something like this:  

// Panel  
class MyPanel extends Panel {  

private LoadableDetachableModel abc;  
private LoadableDetachableModel def;  
private LoadableDetachableModel ghi;  

void onDetach() {  
abc.detach();  
def.detach();  
ghi.detach();  
}  

MyPanel(final IModel cacheLDM) {  

// create an LDM that uses the cache LDM and an expression  
abc = new LoadableDetachableExpressionModel(cacheLDM, "a.b.c");  

// another one based on abc  
def = new LoadableDetachableExpressionModel(abc, "d.e.f");  

// create a panel for DEF object  
Panel subPanel = new SubPanel(def);  
this.add(subPanel);  

// create a model for a repeating list of GHI  
ghi = new LoadableDetachableExpressionModel(abc, "g.h.i");  

// create a repeating section for GHIs  
ListPanel listPanel = new ListPanel("listPanel", ghi) {  
@Override  
public Component createItemComponent(String id, IModel  
model, Item item) {  
return new GHIPanel(id, model, isReadonly, mode);  
}  

@Override  
public void addItem(AjaxRequestTarget target) {  
// uses abc model from above to add the new GHI  
abc.getObject().addNewGHI();  
}  

@Override  
public IModel getItemModel(GHI item) {  
// create an LDM for the GHI item that might use the items's  
id internally  
// to load  
return new LoadableDetachableExpressionModel(abc, item);  
}  

@Override  
public void removeItem(GHI item, AjaxRequestTarget target) {  
abc.getObject().deleteGHI(item);  
}

Re: Wicket model problem

2016-02-19 Thread gmparker2000

It's hard to give specifics as the form is very complex.  I do have a general
example of a pattern prevalent throughout the form.  The pseudo code goes
something like this:

// Page
class MyPage extends Page {
onInitialize() {
Panel p = PanelFactory.createPanel("myPanel", "myObject");
this.add(p);
}
}

// Factory for creating panels that use a document cache based loadable
detachable
// model
class PanelFactory {
Panel createPanel(String panelName, String cachedObjectName) {
// uses the document name to retrieve doc from the cache using it's
name
DocumentCacheLDM ldm = new DocumentCacheLDM(cachedObjectName);

// return a panel initialized with the model
if ("myPanel".equals(panelName)) {
return new MyPanel(ldm);
}


}
}

// Panel
class MyPanel extends Panel {

MyPanel(final IModel cacheLDM) {

// create an LDM that uses the cache LDM and an expression.  Note
that it is marked final
// so it can be used in the list panel below
final LoadableDetachableModel abc = new
LoadableDetachableExpressionModel(cacheLDM, "a.b.c");

// another one based on abc
LoadableDetachableModel def = new
LoadableDetachableExpressionModel(abc, "d.e.f");

// create a panel for DEF object
Panel subPanel = new SubPanel(def);
this.add(subPanel);

// create a model for a repeating list of GHI
LoadableDetachableModel ghi = new
LoadableDetachableExpressionModel(abc, "g.h.i");

// create a repeating section for GHIs
ListPanel listPanel = new ListPanel("listPanel", ghi) {
@Override
public Component createItemComponent(String id, IModel
model, Item item) {
return new GHIPanel(id, model, isReadonly, mode);
}

@Override
public void addItem(AjaxRequestTarget target) {
// uses abc model from above to add the new GHI
abc.getObject().addNewGHI();
}

@Override
public IModel getItemModel(GHI item) {
// create an LDM for the GHI item that might use the items's
id internally
// to load
return new LoadableDetachableExpressionModel(abc, item);
}

@Override
public void removeItem(GHI item, AjaxRequestTarget target) {
abc.getObject().deleteGHI(item);
}
}

this.add(listPanel);
  }
}


This pattern, in our case, seems to end with a bunch of models that never
get detached.  Therefore on subsequent request we end up with some parts of
the form reattached to the document from the cache and other parts attached
to orphaned transient models from their unattached models.  Then when you
submit the form the components that are attached to the cached object update
the correct model object but the ones that didn't get detached properly
update the orphaned model objects.  So we end up with data lose.  To get
this working we changed the MyPanel class to something like this:

// Panel
class MyPanel extends Panel {

private LoadableDetachableModel abc;
private LoadableDetachableModel def;
private LoadableDetachableModel ghi;

void onDetach() {
abc.detach();
def.detach();
ghi.detach();
}

MyPanel(final IModel cacheLDM) {

// create an LDM that uses the cache LDM and an expression
abc = new LoadableDetachableExpressionModel(cacheLDM, "a.b.c");

// another one based on abc
def = new LoadableDetachableExpressionModel(abc, "d.e.f");

// create a panel for DEF object
Panel subPanel = new SubPanel(def);
this.add(subPanel);

// create a model for a repeating list of GHI
ghi = new LoadableDetachableExpressionModel(abc, "g.h.i");

// create a repeating section for GHIs
ListPanel listPanel = new ListPanel("listPanel", ghi) {
@Override
public Component createItemComponent(String id, IModel
model, Item item) {
return new GHIPanel(id, model, isReadonly, mode);
}

@Override
public void addItem(AjaxRequestTarget target) {
// uses abc model from above to add the new GHI
abc.getObject().addNewGHI();
}

@Override
public IModel getItemModel(GHI item) {
// create an LDM for the GHI item that might use the items's
id internally
// to load
return new LoadableDetachableExpressionModel(abc, item);
}

@Override
public void removeItem(GHI item, AjaxRequestTarget target) {
abc.getObject().deleteGHI(item);
}
}

this.add(listPanel);
  }
}

[ANNOUNCE] Apache Wicket 7.2.0 released

2016-02-19 Thread Martijn Dashorst

The Apache Wicket PMC is proud to announce Apache Wicket 7.2.0!

This release marks another minor release of Wicket 7. We
use semantic versioning for the development of Wicket, and as such no
API breaks are present breaks are present in this release compared to
7.0.0.

Using this release
--

With Apache Maven update your dependency to (and don't forget to
update any other dependencies on Wicket projects to the same version):


org.apache.wicket
wicket-core
7.2.0


Or download and build the distribution yourself, or use our
convenience binary package

 * Source: http://www.apache.org/dyn/closer.cgi/wicket/7.2.0
 * Binary: http://www.apache.org/dyn/closer.cgi/wicket/7.2.0/binaries

Upgrading from earlier versions
---

If you upgrade from 7.y.z this release is a drop in replacement. If
you come from a version prior to 7.0.0, please read our Wicket 7
migration guide found at

 * http://s.apache.org/wicket7migrate

Have fun!

— The Wicket team




The signatures for the source release artefacts:


Signature for apache-wicket-7.2.0.zip:

-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iEYEABECAAYFAlafnDAACgkQJBX8W/xy/UUzqQCgzA+MfKSc+nVcUm5aUnYQZ1MY
AUwAoNAICFNraXprKN5+1Ml+MGJfEr+u
=Z9If
-END PGP SIGNATURE-

Signature for apache-wicket-7.2.0.tar.gz:

-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iEYEABECAAYFAlafnDAACgkQJBX8W/xy/UWO7ACcD3JS80Xr52TXTqLF6BUwmp0L
XrQAn2hQvSEJHndvIegfrkGL1eNeFuCf
=+jP1
-END PGP SIGNATURE-



CHANGELOG for 7.2.0:

** Bug

* [WICKET-6001] - Exception raised while refreshing a page with
queued components missing in the markup
* [WICKET-6002] - FileUploadField makes form-component models
become null on submit
* [WICKET-6006] - ModalWindow.closeCurrent() causes 414 status error
* [WICKET-6010] - Downloading filenames containing ',' or ';' gives problems
* [WICKET-6011] - NPE in case DebugBar is added to AjaxRequestTarget
* [WICKET-6013] - CLONE - AjaxFallbackOrderByBorder
wicketOrder[Up|Down|None] class missing in 7.1.0
* [WICKET-6014] - TransparentWebMarkupContainer breaks
OnChangeAjaxBehavior for Select2
* [WICKET-6017] - Tests fail when executed with not expected locale
* [WICKET-6018] - TransparentWebMarkupContainer is not really "transparent"
* [WICKET-6020] - GuiceFieldValueFactory returns the NULL_SENTINEL
from the cache
* [WICKET-6021] - ConcurrentModificationException in
MarkupContainer#iterator#next
* [WICKET-6024] - Possible issue with Border and
LoadableDetachableModel in 7.1.0
* [WICKET-6026] - Problem in detecting child id on nested 
* [WICKET-6027] - Nested TransparentWebMarkupContainer, markup of
inner component not found
* [WICKET-6028] - Detach called on enclosure component while it
had a non-empty queue
* [WICKET-6031] - NPE in PackageResourceReference#getResource()
when there is no request
* [WICKET-6032] - Wicket.Ajax.done() called twice on redirect
* [WICKET-6034] - AjaxFallbackOrderByBorder does not generate any
CSS class in order link
* [WICKET-6036] - Failure to process markup with nested tags inside a Label
* [WICKET-6037] - ModalWindow vulnerable to Javascript injection
through title model
* [WICKET-6043] - Cannot set wicket:enclosure on queued component
in ListView
* [WICKET-6044] - AjaxFormChoiceComponentUpdatingBehavior:
Duplicate input values according to WICKET-5948
* [WICKET-6045] - ListView NullPointerException when viewSize is
set explicitly
* [WICKET-6048] - German Translation for EqualInputValidator wrong
* [WICKET-6050] - Wicket Ajax (Wicket.From.serializeElement)
causes 400 bad request
* [WICKET-6052] - CSS header contribution overlap
* [WICKET-6058] - Error in calculation of byte ranges
* [WICKET-6059] - TransparentWebMarkupContainer can not resolve
autocomponents in its parent
* [WICKET-6062] - MockHttpSession should renew its id after invalidation
* [WICKET-6063] - Add support for WebSocketRequest#getUrl() and
other properties which are available in the handshake request
* [WICKET-6064] - WebSocketResponse.sendRedirect could be
supported with ...
* [WICKET-6065] - Calling
http://examples7x.wicket.apache.org/resourceaggregation/ generate
Internal error
* [WICKET-6068] - The key RangeValidator.exact is not mapped in
Application_de.properties
* [WICKET-6076] - Problem with queued components and enclosure
* [WICKET-6077] - Border's body is not added as a child due to dequeuing

** Improvement

* [WICKET-5950] - Model and GenericBaseModel could both implement
IObjectClassAwareModel
* [WICKET-5969] - Please give us access to PageTable.index pageId queue
* [WICKET-6015] - AjaxFallbackOrderByBorder/Link should support

[ANNOUNCE] Wicket 7.2.0 released

2016-02-19 Thread Martijn Dashorst

The Apache Wicket PMC is proud to announce Apache Wicket 7.2.0!

This release marks another minor release of Wicket 7. We
use semantic versioning for the development of Wicket, and as such no
API breaks are present breaks are present in this release compared to
7.0.0.

Using this release
--

With Apache Maven update your dependency to (and don't forget to
update any other dependencies on Wicket projects to the same version):


org.apache.wicket
wicket-core
7.2.0


Or download and build the distribution yourself, or use our
convenience binary package

 * Source: http://www.apache.org/dyn/closer.cgi/wicket/7.2.0
 * Binary: http://www.apache.org/dyn/closer.cgi/wicket/7.2.0/binaries

Upgrading from earlier versions
---

If you upgrade from 7.y.z this release is a drop in replacement. If
you come from a version prior to 7.0.0, please read our Wicket 7
migration guide found at

 * http://s.apache.org/wicket7migrate

Have fun!

— The Wicket team




The signatures for the source release artefacts:


Signature for apache-wicket-7.2.0.zip:

-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iEYEABECAAYFAlafnDAACgkQJBX8W/xy/UUzqQCgzA+MfKSc+nVcUm5aUnYQZ1MY
AUwAoNAICFNraXprKN5+1Ml+MGJfEr+u
=Z9If
-END PGP SIGNATURE-

Signature for apache-wicket-7.2.0.tar.gz:

-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iEYEABECAAYFAlafnDAACgkQJBX8W/xy/UWO7ACcD3JS80Xr52TXTqLF6BUwmp0L
XrQAn2hQvSEJHndvIegfrkGL1eNeFuCf
=+jP1
-END PGP SIGNATURE-



CHANGELOG for 7.2.0:

** Bug

* [WICKET-6001] - Exception raised while refreshing a page with
queued components missing in the markup
* [WICKET-6002] - FileUploadField makes form-component models
become null on submit
* [WICKET-6006] - ModalWindow.closeCurrent() causes 414 status error
* [WICKET-6010] - Downloading filenames containing ',' or ';' gives problems
* [WICKET-6011] - NPE in case DebugBar is added to AjaxRequestTarget
* [WICKET-6013] - CLONE - AjaxFallbackOrderByBorder
wicketOrder[Up|Down|None] class missing in 7.1.0
* [WICKET-6014] - TransparentWebMarkupContainer breaks
OnChangeAjaxBehavior for Select2
* [WICKET-6017] - Tests fail when executed with not expected locale
* [WICKET-6018] - TransparentWebMarkupContainer is not really "transparent"
* [WICKET-6020] - GuiceFieldValueFactory returns the NULL_SENTINEL
from the cache
* [WICKET-6021] - ConcurrentModificationException in
MarkupContainer#iterator#next
* [WICKET-6024] - Possible issue with Border and
LoadableDetachableModel in 7.1.0
* [WICKET-6026] - Problem in detecting child id on nested 
* [WICKET-6027] - Nested TransparentWebMarkupContainer, markup of
inner component not found
* [WICKET-6028] - Detach called on enclosure component while it
had a non-empty queue
* [WICKET-6031] - NPE in PackageResourceReference#getResource()
when there is no request
* [WICKET-6032] - Wicket.Ajax.done() called twice on redirect
* [WICKET-6034] - AjaxFallbackOrderByBorder does not generate any
CSS class in order link
* [WICKET-6036] - Failure to process markup with nested tags inside a Label
* [WICKET-6037] - ModalWindow vulnerable to Javascript injection
through title model
* [WICKET-6043] - Cannot set wicket:enclosure on queued component
in ListView
* [WICKET-6044] - AjaxFormChoiceComponentUpdatingBehavior:
Duplicate input values according to WICKET-5948
* [WICKET-6045] - ListView NullPointerException when viewSize is
set explicitly
* [WICKET-6048] - German Translation for EqualInputValidator wrong
* [WICKET-6050] - Wicket Ajax (Wicket.From.serializeElement)
causes 400 bad request
* [WICKET-6052] - CSS header contribution overlap
* [WICKET-6058] - Error in calculation of byte ranges
* [WICKET-6059] - TransparentWebMarkupContainer can not resolve
autocomponents in its parent
* [WICKET-6062] - MockHttpSession should renew its id after invalidation
* [WICKET-6063] - Add support for WebSocketRequest#getUrl() and
other properties which are available in the handshake request
* [WICKET-6064] - WebSocketResponse.sendRedirect could be
supported with ...
* [WICKET-6065] - Calling
http://examples7x.wicket.apache.org/resourceaggregation/ generate
Internal error
* [WICKET-6068] - The key RangeValidator.exact is not mapped in
Application_de.properties
* [WICKET-6076] - Problem with queued components and enclosure
* [WICKET-6077] - Border's body is not added as a child due to dequeuing

** Improvement

* [WICKET-5950] - Model and GenericBaseModel could both implement
IObjectClassAwareModel
* [WICKET-5969] - Please give us access to PageTable.index pageId queue
* [WICKET-6015] - AjaxFallbackOrderByBorder/Link should support

[ANNOUNCE] Wicket 6.22.0 released

2016-02-19 Thread Martijn Dashorst

The Apache Wicket PMC is proud to announce Apache Wicket 6.22.0!

This release marks another minor release of Wicket 6. We
use semantic versioning for the development of Wicket, and as such no
API breaks are present breaks are present in this release compared to
6.0.0.

Using this release
--

With Apache Maven update your dependency to (and don't forget to
update any other dependencies on Wicket projects to the same version):


org.apache.wicket
wicket-core
6.22.0


Or download and build the distribution yourself, or use our
convenience binary package

 * Source: http://www.apache.org/dyn/closer.cgi/wicket/6.22.0
 * Binary: http://www.apache.org/dyn/closer.cgi/wicket/6.22.0/binaries

Upgrading from earlier versions
---

If you upgrade from 6.y.z this release is a drop in replacement. If
you come from a version prior to 6.0.0, please read our Wicket 6
migration guide found at

 * http://s.apache.org/wicket6migrate

Have fun!

— The Wicket team




The signatures for the source release artefacts:


Signature for apache-wicket-6.22.0.zip:

-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iEYEABECAAYFAla4/iQACgkQJBX8W/xy/UWCvwCfaaX/doVH2CLhtcH9Og1a/aSd
wikAnRDbMkTJXWB9qWpqorTpxSWfLJdV
=vzR8
-END PGP SIGNATURE-

Signature for apache-wicket-6.22.0.tar.gz:

-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iEYEABECAAYFAla4/iQACgkQJBX8W/xy/UXM1gCdFIjlix9U97vQsovYTH9sBn7C
8GYAoJPjDABEko7/jp/sfr8NFmJ0pMY1
=ZSb4
-END PGP SIGNATURE-



CHANGELOG for 6.22.0:

** Bug

* [WICKET-6006] - ModalWindow.closeCurrent() causes 414 status error
* [WICKET-6017] - Tests fail when executed with not expected locale
* [WICKET-6020] - GuiceFieldValueFactory returns the NULL_SENTINEL
from the cache
* [WICKET-6030] - Support
/META-INF/services/org.apache.wicket.IInitializer (backport to 6.x)
* [WICKET-6032] - Wicket.Ajax.done() called twice on redirect
* [WICKET-6037] - ModalWindow vulnerable to Javascript injection
through title model
* [WICKET-6040] - DebugBar not serializable exception
* [WICKET-6044] - AjaxFormChoiceComponentUpdatingBehavior:
Duplicate input values according to WICKET-5948
* [WICKET-6048] - German Translation for EqualInputValidator wrong
* [WICKET-6050] - Wicket Ajax (Wicket.From.serializeElement)
causes 400 bad request
* [WICKET-6052] - CSS header contribution overlap
* [WICKET-6062] - MockHttpSession should renew its id after invalidation
* [WICKET-6063] - Add support for WebSocketRequest#getUrl() and
other properties which are available in the handshake request
* [WICKET-6064] - WebSocketResponse.sendRedirect could be
supported with ...
* [WICKET-6068] - The key RangeValidator.exact is not mapped in
Application_de.properties
* [WICKET-6069] - OnChangeAjaxBehavior does not work if the url
contains a request parameter with same name as wicket id
* [WICKET-6084] - ajax request failure handler receives incorrect arguments
* [WICKET-6085] - AjaxTimerBehavior with failure handler cause
memory leak in browser
* [WICKET-6087] - Invalid
AbstractRequestWrapperFactory.needsWrapper method scope: package -
cannot create a custom implementation

** Improvement

* [WICKET-5950] - Model and GenericBaseModel could both implement
IObjectClassAwareModel
* [WICKET-5969] - Please give us access to PageTable.index pageId queue
* [WICKET-6019] - Remove 'final' modifier for
Localizer#getStringIgnoreSettings() methods
* [WICKET-6051] - Improve performance of CssUrlReplacer
* [WICKET-6054] - Provide a factory method for the
WebSocketResponse & WebSocketRequest
* [WICKET-6073] - Use NIO Jetty connector for the quickstart
* [WICKET-6081] - Add "assertNotRequired" to the WicketTester

** Task

* [WICKET-6071] - Upgrade jQuery to 1.12 / 2.2.0

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

[ANNOUNCE] WicketStuff 6.22.0 is released

2016-02-19 Thread Martin Grigorov

Hi,

WicketStuff core 6.22.0 based on Apache Wicket 6.22.0 is released and
available at Maven Central.

The changelog since 6.21.0 is:

Martin Tzvetanov Grigorov (5):
  [build] Use Wicket 6.22.0-SNAPSHOT
  [fast2] Update fast serializer to 2.43
  WICKET-6091 NPE in RequestLoggerRequestCycleListener when using
native-websockets
  Wicket 6.22.0
  6.22.0

Jurriaan Pruijs (3):
  Test to demonstrate that userProvidedResourceReferences (in
JQueryAjaxBehavior) is shared between instances
  Fix shared userProvidedResourceReferences
  Fix usage of diamond operator in wicket 6

Martin Grigorov (3):
  Merge pull request #439 from VaclavC/pathfix
  Merge pull request #442 from
qlp/fix-rebase-userProvidedResourceReferences-in-wicket-6
  Merge pull request #458 from rene-d-menoto/wicket-6.x

Maxim Solodovnik (2):
  Merge pull request #435 from tgoetz/wicket-6.x
  decebals/wicket-dashboard 6.0 is moved to wicketstuff

René Dieckmann (1):
  Initial wicket-6 version of wicketstuff jamon contribution.

Sven Meier (1):
  WICKET-5950 model implements IObjectClassAwareModel now, so use own
generic model which loses type through erasure

Tom Götz (1):
  Backport: revert non-ajax support for select2 (analog to [d46d150])

Vaclav Cermak (1):
  Fixed GMAP_API_URL to use  instead of &


The WicketStuff team!

Quesitont about .repeater.DataTableFilterToolbarPage : mutliple fitered

Re: Wicketstuff editable grid - 7.1.0

Re: Wicket model problem

Re: Wicketstuff editable grid - 7.1.0

Re: Wicketstuff editable grid - 7.1.0

Re: Wicket model problem

Re: Wicket model problem

Re: Wicket model problem

Re: Wicket model problem

Re: Wicket model problem

[ANNOUNCE] Apache Wicket 7.2.0 released

[ANNOUNCE] Wicket 7.2.0 released

[ANNOUNCE] Wicket 6.22.0 released

[ANNOUNCE] WicketStuff 6.22.0 is released

14 matches

Site Navigation

Mail list logo

Footer information