Re: Change column visibility or text based on combo selected value
Hi,
you should use a column that always displays the correct text:
new AbstractColumn(Model.of("Text")) {
public void populateItem(Item> cellItem, String
componentId, IModel rowModel) {
cellItem.add(new Label(componentId), new
AbstractReadOnlyModel() {
public String getObject() {
return getColumnText();
}
});
}
}
This way you just have to update the whole table via Ajax when your dropDown
changes, e.g.
dropDown.add(new AjaxFormChoiceComponentUpdatingBehavior() {
protected void onUpdate(AjaxRequestTarget target) {
target.add(table);
}
});
Hope this helps
Sven
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Change-column-visibility-or-text-based-on-combo-selected-value-tp4674943p4674945.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
Change column visibility or text based on combo selected value
Hi, I'm using wicket 6. I have a combo and a table that contains a fixed number of rows and columns. Based on the value chosen inside the combo, the first column of the table should change it's text. Basically the first column contains in every cell, the same text, that needs to change when something else is selected in the combo. Could you please advise what is the best approach to do this? Thank you -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Change-column-visibility-or-text-based-on-combo-selected-value-tp4674943.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: Increased memory usage from 6.23 to 7.3
Hi, On Mon, Jun 20, 2016 at 2:16 PM, Mathias Decrock wrote: > Hey all, > > We're seeing a large increase in memory consumption from Wicket 6.23 to > 7.3, it seems that most of the increase comes from classes extending > ListView that contain a large amount of items (more than 200 items in each > ListView). > > The application could run with Xmx800m without any performance issues on > Wicket 7, and now on Wicket 8 the heap fills up and the application becomes > Here you mean "from 6 to 7". > unresponsive even after increasing the heap size to Xmx2g. > > Could this be related to this change to the base class MarkupContainer > "WICKET-5983: mostly linear performance in MarkupContainer.add" (commit > 26cecdc6fabb8c4dadf457a2e4b22ef8c6eb1ea3)? > > In a later commit (7be920d4403d719e26d2a131454928c086a7317c) there is a > comment added: > /** > * The threshold where we start using a Map to store children in, replacing > a List. Adding > * components to a list is O(n), and to a map O(1). The magic number is 24, > due to a Map using > * more memory to store its elements and below 24 children there's no > discernible difference > * between adding to a Map or a List. > * > * We have focused on adding elements to a list, instead of indexed lookups > because adding is an > * action that is performed very often, and lookups often are done by > component IDs, not index. > */ > Yes, this is also the first thing I thought about. Can you create a quickstart that shows the problem ? This way it will be easier for us to investigate where is the problem. Thanks! > > This seems to indicate that this could increase memory usage, but could the > effect be this noticeable? > > Thanks, > Mathias > > -- > > > DISCLAIMER > > http://www.tvh.com/glob/en/email-disclaimer > > "This message is delivered to all addressees subject to the conditions > set forth in the attached disclaimer, which is an integral part of this > message." >
Re: Increased memory usage from 6.23 to 7.3
Hello, I doubt that would have that kind of difference. Have you checked with a profiler where the memory is going? mvg, On Mon, Jun 20, 2016 at 2:16 PM, Mathias Decrock wrote: > Hey all, > > We're seeing a large increase in memory consumption from Wicket 6.23 to > 7.3, it seems that most of the increase comes from classes extending > ListView that contain a large amount of items (more than 200 items in each > ListView). > > The application could run with Xmx800m without any performance issues on > Wicket 7, and now on Wicket 8 the heap fills up and the application becomes > unresponsive even after increasing the heap size to Xmx2g. > > Could this be related to this change to the base class MarkupContainer > "WICKET-5983: mostly linear performance in MarkupContainer.add" (commit > 26cecdc6fabb8c4dadf457a2e4b22ef8c6eb1ea3)? > > In a later commit (7be920d4403d719e26d2a131454928c086a7317c) there is a > comment added: > /** > * The threshold where we start using a Map to store children in, replacing > a List. Adding > * components to a list is O(n), and to a map O(1). The magic number is 24, > due to a Map using > * more memory to store its elements and below 24 children there's no > discernible difference > * between adding to a Map or a List. > * > * We have focused on adding elements to a list, instead of indexed lookups > because adding is an > * action that is performed very often, and lookups often are done by > component IDs, not index. > */ > > This seems to indicate that this could increase memory usage, but could the > effect be this noticeable? > > Thanks, > Mathias > > -- > > > DISCLAIMER > > http://www.tvh.com/glob/en/email-disclaimer > > "This message is delivered to all addressees subject to the conditions > set forth in the attached disclaimer, which is an integral part of this > message." - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Increased memory usage from 6.23 to 7.3
Hey all, We're seeing a large increase in memory consumption from Wicket 6.23 to 7.3, it seems that most of the increase comes from classes extending ListView that contain a large amount of items (more than 200 items in each ListView). The application could run with Xmx800m without any performance issues on Wicket 7, and now on Wicket 8 the heap fills up and the application becomes unresponsive even after increasing the heap size to Xmx2g. Could this be related to this change to the base class MarkupContainer "WICKET-5983: mostly linear performance in MarkupContainer.add" (commit 26cecdc6fabb8c4dadf457a2e4b22ef8c6eb1ea3)? In a later commit (7be920d4403d719e26d2a131454928c086a7317c) there is a comment added: /** * The threshold where we start using a Map to store children in, replacing a List. Adding * components to a list is O(n), and to a map O(1). The magic number is 24, due to a Map using * more memory to store its elements and below 24 children there's no discernible difference * between adding to a Map or a List. * * We have focused on adding elements to a list, instead of indexed lookups because adding is an * action that is performed very often, and lookups often are done by component IDs, not index. */ This seems to indicate that this could increase memory usage, but could the effect be this noticeable? Thanks, Mathias -- DISCLAIMER http://www.tvh.com/glob/en/email-disclaimer "This message is delivered to all addressees subject to the conditions set forth in the attached disclaimer, which is an integral part of this message."
