I need to validate something about several Wicket input fields of type TextField<BigDecimal> (namely that the sum of percentages is 100). There are one to many such input fields; thing is, I don't know in advance how many.
(simplified example)
private class PercentageValidator extends AbstractFormValidator {
#Override
public FormComponent<?>[] getDependentFormComponents() {
// ...
}
#Override
public void validate(Form<?> form) {
List<TextField<BigDecimal>> fields = // TODO
// the actual validation where the value of every field is needed
}
}
Java code for the ListView:
ListView<?> listView = new ListView<PropertyShare>("shares", shares) {
#Override
protected void populateItem(ListItem<PropertyShare> item) {
// ...
item.add(new TextField<BigDecimal>("share", ... model ...));
}
};
HTML:
<tr wicket:id="shares">
<td> ... </td>
<td>
<input wicket:id="share" type="text" size="4"> %
</td>
</tr>
I tried keeping every TextField in a collection on the Page, but this approach fails as the populateItem() method of the enclosing ListView gets called not only the the Page is first created, so duplicate fields get added to the collection. (I couldn't figure out an easy way to keep it duplicate-free.)
The fact that ListView is used also seems to somewhat complicate finding the fields from the form object in the validate() method. I suppose I need to get the ListView with form.get("shares") and iterate through its children?
What's the "right way" to access any number of fields enclosed by a repeater such as ListView?
An alternative approach would be to subclass TextField and then use a Visitor to pick out all the descendant components of your subclass.
This way you can avoid unchecked casting and you don't have to rely on the ids, which isn't a very robust approach.
Edit: in practice, it would look something like this:
The subclass:
private static class ShareField extends TextField<BigDecimal> {
// ...
}
Helper method that finds all ShareFields from the form:
private List<ShareField> findShareFields(Form form) {
final List<ShareField> fields = Lists.newArrayList();
form.visitChildren(ShareField.class, new IVisitor<ShareField>() {
#Override
public Object component(ShareField component) {
fields.add(component);
return CONTINUE_TRAVERSAL;
}
});
return fields;
}
Right, while writing the question, it dawned on me that simply looping through the children of form.get("shares") and getting the field with id "share" would probably work.
It indeed does. Here's a helper method that finds the "share" fields:
#SuppressWarnings("unchecked")
private List<TextField<BigDecimal>> findFields(Form form) {
List<TextField<BigDecimal>> fields = Lists.newArrayList();
MarkupContainer container = (MarkupContainer) form.get("shares");
for (Iterator<? extends Component> it = container.iterator(); it.hasNext();) {
MarkupContainer c = (MarkupContainer) it.next();
fields.add((TextField<BigDecimal>) c.get("share"));
}
return fields;
}
However, there are three somewhat ugly casts in the above method, and one of those (Component -> TextField<BigDecimal>) produces an "unchecked cast" warning.
If you can clean up this solution, or know of better approaches, feel free to comment or post other answers!
As far I see you did not set the reuse items property on the list view; from the java doc:
If true re-rendering the list view is more efficient if the windows doesn't get changed at all or if it gets scrolled (compared to paging). But if you modify the listView model object, than you must manually call listView.removeAll() in order to rebuild the ListItems. If you nest a ListView in a Form, ALLWAYS set this property to true, as otherwise validation will not work properly.
However you also can iterate over the children of the listview with a Visitor. Wicket always keeps track of the components you added of the view.
Related
I am working on a project using ISIS 1.16.2. I have a superclass, called ConfigurationItem, which has some common properties (name, createdTimestamp etc.).
For example it has a delete action method, annotated with #Action(invokeOn = InvokeOn.OBJECT_AND_COLLECTION, ...), which I need to be callable from entitys detail view as well as from collection views with selection boxes.
Example:
public class ConfigurationItem {
#Action(
invokeOn = InvokeOn.OBJECT_AND_COLLECTION,
semantics = SemanticsOf.NON_IDEMPOTENT_ARE_YOU_SURE,
domainEvent = DeletedDomainEvent.class)
public Object delete() {
repositoryService.remove(this);
return null;
}
// ...
}
public class ConfigurationItems {
#Action(semantics = SemanticsOf.SAFE)
public List<T> listAll() {
return repositoryService.allInstances(<item-subclass>.class);
}
// ...
}
This works pretty well but the "invokeOn" annotation is now deprecated. The JavaDoc says that one should switch to #Action(associateWith="...") but I don't know how to transfer the semantics of 'InvokeOn' since I have no collection field for reference.
Instead I only have the collection of objects returned by the database retrieve action.
My question is: How do I transfer the deprecated #Action(invokeOn=...) semantics to the new #Action(associateWith="...") concept for collection return values with no backed property field?
Thanks in advance!
Good question, this obviously isn't explained well enough in the Apache Isis documentation.
The #Action(invokeOn=InvokeOn.OBJECT_AND_COLLECTION) has always been a bit of a kludge, because it involves invoking an action against a standalone collection (which is to say, the list of object returned from a previous query). We don't like this because there is no "single" object to invoke the action on.
When we implemented that feature, the support for view models was nowhere near as comprehensive as it now is. So, our recommendation now is, rather than returning a bare standalone collection, instead wrap it in a view model which holds the collection.
The view model then gives us a single target to invoke some behaviour on; the idea being that it is the responsibility of the view model to iterate over all selected items and invoke an action on them.
With your code, we can introduce SomeConfigItems as the view model:
#XmlRootElement("configItems")
public class SomeConfigItems {
#lombok.Getter #lombok.Setter
private List<ConfigurationItem> items = new ArrayList<>();
#Action(
associateWith = "items", // associates with the items collection
semantics = SemanticsOf.NON_IDEMPOTENT_ARE_YOU_SURE,
domainEvent = DeletedDomainEvent.class)
public SomeConfigItems delete(List<ConfigurationItem> items) {
for(ConfigurationItem item: items) {
repositoryService.remove(item);
}
return this;
}
// optionally, select all items for deletion by default
public List<ConfigurationItem> default0Delete() { return getItems(); }
// I don't *think* that a choices method is required, but if present then
// is the potential list of items for the argument
//public List<ConfigurationItem> choices0Delete() { return getItems(); }
}
and then change the ConfigurationItems action to return this view model:
public class ConfigurationItems {
#Action(semantics = SemanticsOf.SAFE)
public SelectedItems listAll() {
List<T> items = repositoryService.allInstances(<item-subclass>.class);
return new SelectedItems(items);
}
}
Now that you have a view model to represent the output, you'll probably find other things you can do with it.
Hope that makes sense!
I am attempting to build a web application using Wicket and OrientDB. I am trying to avoid writing/maintaining a flat Java class that represents each Class of vertex as a POJO (like an ORM). Rather, I am sending the vertices themselves all the way to the web layer. I access the properties via:
vertex.getProperty("propertyName");
Meaning that the properties themselves are not member variables of Vertex and thus cannot be accessed through normal getters/setters. I am running into an issue with Wicket because many components depend on a "PropertyModel" style implementation where you pass in a Model that represents one of the member variables of the class you're working with, and the data is stored in that member variable.
I have this DataView that pulls the properties of a vertex out into a Label and a TextField.
public VertexViewer(final PageParameters pageParameters, OrientVertex vertex)
this.vertex = vertex;
this.properties = this.vertex.getProperties();
List<String> keyList = new ArrayList<>();
keyList.addAll(this.vertex.getPropertyKeys());
final DataView<String> propertiesView = new DataView<String>("properties", new ListDataProvider<>(keyList)) {
#Override
protected void populateItem(Item item) {
String key = item.getModelObject().toString();
item.add(new Label("property_name", key));
item.add(new TextField<String>("edit_field", new Model<String>(properties.get(key).toString())));
}
};
add(propertiesViewer);
}
And the HTML:
<wicket:extend>
<div wicket:id="properties" style="display: table-row;">
<div wicket:id="property_name" style="display: table-cell;"></div>
<input wicket:id="edit_field" type="text" style="display: table-cell;"/>
</div>
</wicket:extend>
This renders exactly how I want it to, but does anyone have any recommendations on how I can save the data that is being changed in the TextFields? I can't use a model of a member variable like I would normally do on a Form because I don't ever know exactly what/how many properties are going to be in a vertex. Am I going about this in completely the wrong way? Any help is much appreciated.
Take a look at https://github.com/OrienteerDW/wicket-orientdb.
The developer of this library also created https://issues.apache.org/jira/browse/WICKET-5623, but this improvement didn't get much support. Please feel free to vote for it if you think it is needed.
So, after much trial and error (mostly error) I found a patttern that gets around Wicket's NoSQL deficiencies and doesn't involve manually creating member variables to make Models of.
I get the Map<String, Object> from vertex.getProperties() and then create a copy of it.
private Map<String, Object> realProperties = baseVertex.getProperties();
private Map<String, Object> dummyProperties = new HashMap<>();
dummyProperties.putAll(realProperties);
This allows me to use the values in the dummyProperties as Models to store data.
List<String> keyList = new ArrayList<>();
keyList.addAll(getDummyProperties().keySet());
final DataView<String> propertiesView = new DataView<String>("properties", new ListDataProvider<>(keyList)) {
#Override
protected void populateItem(Item item) {
String key = item.getModelObject().toString();
item.add(new Label("property_name", key));
item.add(new TextField<String>("edit_field", new PropertyModel<String>(getDummyProperties(), key)));
}
};
From there, I put the DataView on a Form with an AjaxButton that compares the potential new values in the TextFields to the original values through some convoluted looping.
AjaxButton saveButton = new AjaxButton("saveButton") {
#Override
protected void onSubmit(AjaxRequestTarget target, Form<?> form) {
super.onSubmit(target, form);
Map<String, Object> changedProperties = new HashMap<>();
// for each entry in the dummy values linked via PropertyModel to the TextField input
for (Map.Entry<String,Object> dummyEntry : getDummyProperties().entrySet()) {
// for each entry in the
for (Map.Entry<String,Object> realEntry : baseVertex.getProperties().entrySet()) {
// if the keys match
if (dummyEntry.getKey().equals(realEntry.getKey())) {
// if the value has changed
if (!dummyEntry.getValue().equals(realEntry.getValue())){
// value in textField differs from value in database
changedProperties.put(dummyEntry.getKey(),dummyEntry.getValue());
}
}
}
}
DBWorker worker = new DBWorker();
// perform the update
worker.updateVertex(recordID, changedProperties);
// pull the fresh vertex out and pass it to the page again
setResponsePage(new VertexViewer(new PageParameters(), new CustomVertex(worker.getVertexByID(recordID))));
}
};
This ends up evaluating the new values against the old, writing the new ones back to the database, pulling back the fresh vertex and calling a new ViewerPage that accepts the updated vertex as an argument.
This works as intended, is generic to the class of vertex/number of properties, and prevents me from having to maintain ORM style Classes for each vertex class.
This feels like a pretty standard question and has probably been asked before, but I found it hard to find because it is hard to define in words. So if this is a duplicate, go ahead and redirect me!
I'm using Vaadin to build this web app, but that shouldn't matter to the problem at hand, unless there is an even better way of solving this through some Vaadin magic.
I have three classes:
Table
FilterGenerator
Container
My "design" looks like this:
The Container adds some properties (column headers) to itself in its constructor
The FilterGenerator #Inject the Container (in order to use the Container's getDistinct() method that gets the distinct items from the container - in order to present them nicely in a ComboBox in the filter)
The Table #Inject the FilterGenerator (in order to table.setFilterGenerator(filterGenerator))
The Table #Inject the Container and calls the containers addItems() method to add items to the container
The Table then adds the container as a datasource
What happens?
What I should have now is a table with a ComboBox in the column header, presenting distinct values to filter.
What I get is a table with a ComboBox in the column header, presenting nothing in the ComboBox, because there are no items in the ComboBox.
This is not surprising, because when the FilterGenerator calls the Containers getDistinct() method, it will get an empty map of <Column, items> back, because at the time of #Inject in the FilterGenerator, the Table hasn't called the Containers addItems() method, so the Container will at this moment be empty.
The question
How should I design this application if I want a component (FilterTable) to get something from a second component (Container), when a third component (Table) is #Inject-ing both forementioned components and it is crucial that the second component (Container) already has been initialized when the first component (FilterGenerator) gets something from it?
I could:
In the Table, simply create a new FilterGenerator. This would work, but it isn't very nice. For example, what happens if some other component wants to use the FilterGenerator?
Go back to xml-configuration in order to "manually" create the instances in the correct order. This would probably work (if I remember correctly), but having instance creation depending on the order of the elements in your xml file doesn't sound very good to me.
Use "programmatic injection" by using the ApplicationContext.getBean() in code. This would probably be even worse than the above alternatives?
Does anyone have any good suggestions on how to solve this triangular drama?
Here is the relevant code:
The Table
#Component
#Scope("session")
public class SampleAppMainTable extends FilteringTable {
#Inject
private SampleAppMainTableContainer sampleAppMainTableContainer;
#Inject
private SampleAppService sampleAppService;
#Inject
private SampleAppMainTableFilterGenerator sampleAppMainTableFilterGenerator;
public SampleAppMainTable() {
//...setting up the table
}
#PostConstruct
public void PostConstruct() throws GeneralSecurityException {
addMainTableItems();
setupMainTable();
}
public void setupMainTable() {
this.setFilterGenerator(sampleAppMainTableFilterGenerator);
sampleAppMainTableFilterGenerator.getCustomFilterComponent("Sample Id");
this.setContainerDataSource(sampleAppMainTableContainer);
}
public void addMainTableItems() {
sampleAppMainTableContainer.addItemsToContainer(sampleAppService.getAllSamples());
}
}
The Container
#Component
#Scope("prototype")
public class SampleAppMainTableContainer extends IndexedContainer {
public void addItemsToContainer(List<Sample> samples) {
// adding items to the container...
}
public Map<String, List<String>> getDistinctProperties() {
// extracting distinct items from the table...
}
}
The FilterGenerator
#Component
#Scope("session")
public class SampleAppMainTableFilterGenerator implements FilterGenerator {
#Inject
SampleAppMainTableContainer sampleAppMainTableContainer;
private List<String> aList = null;
#Override
public AbstractField<?> getCustomFilterComponent(Object propertyId) {
Map<String, List<String>> map = new HashMap<String, List<String>>();
map = sampleAppMainTableContainer.getDistinctProperties();
if (propertyId.equals("Sample Id")) {
ComboBox sampleIdCB = new ComboBox();
BeanItemContainer<String> dataList = new BeanItemContainer<String>(String.class);
List<String> aList = map.get("Sample Id");
dataList.addAll(aList);
sampleIdCB.setContainerDataSource(dataList);
sampleIdCB.setImmediate(true);
return sampleIdCB;
}
return null;
}
// other overridden methods needed...
}
I think you problem is that you do processing logic during the the injection phase. You should wait till everything is set up and then do the processing. You can do something like this by moving the processing logic from the constructor to an initialization method and marking this method with #Inject. By definition injection is done last on methods, i.e., at the time the method gets called by the injector, all the fields are injected.
I used PropertyModel as the part of my DropDownChoice as following:
List<String> choices = Arrays.asList(new String[] { "Library", "School Office", "Science Dept" });
String selected = "Library";
DropDownChoice<String> serviceDDC =
new DropDownChoice<String>("service", new PropertyModel(this, "choices.0"), choices);
Somehow I've got this exception thown:
caused by: org.apache.wicket.WicketRuntimeException: No get method defined for class: class com.samoo.tool.pages.CreatePrintingJob expression: choices
at org.apache.wicket.util.lang.PropertyResolver.getGetAndSetter(PropertyResolver.java:481)
at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter(PropertyResolver.java:332)
at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter(PropertyResolver.java:242)
at org.apache.wicket.util.lang.PropertyResolver.getValue(PropertyResolver.java:95)
at org.apache.wicket.model.AbstractPropertyModel.getObject(AbstractPropertyModel.java:130)
at org.apache.wicket.Component.getDefaultModelObject(Component.java:1724)
....
I know that there's something wrong with the expression. I've been trying different parameter inputs but it still doesn't work. Could anyone help?
Since you're using PropertyModel(this, "choices.0"), Wicket is trying to find a property named choices via reflection through a method getChoices() of the class declaring the PropertyModel. This method doesn't seem to exist in com.samoo.tool.pages.CreatePrintingJob, as the exception is stating.
Also, if that 0 is an index, you should be accessing it with the [index] expression, as this JIRA issue suggests: PropertyModel does not support index only property ("[0]")
However, it seems you want to initialize the DropDownChoice to the first element of choices. But What Wicket will do if you set the DropDownChoice's Model to PropertyModel(this, "choices.[0"]) will be mapping the selection of this DropDownChoice in the following way:
At form rendering time to present the (pre)selected choice, it will use the first element in the choices list.
At form submission time to store the user selected value, it will store the selection in the first position of the choices list.
Summarising, the backing object representing the DropDownChoice's selection would be the first element in the choices list.
So, you'll probably want to use a whole different Model, independent from the choices list, for the backing object representing the DDC's selection.
List<String> choices = Arrays.asList(new String[] { "Library", "School Office",
"Science Dept" });
String selected = "Library";
IModel dropdownModel = new Model<String>(choices[0]);
DropDownChoice<String> serviceDDC =
new DropDownChoice<String>("service", dropdownModel, choices);
You might find the following links useful:
Using the DropDownChoice component
Working with Wicket Models
you are declaring choices inside the method, in order to get the PropertyModel to work you need to declare it on a class level not on a method level. As #Xavi López pointed out the espression is not corret you nedd to use choices.[0]
It is good idea to use IModel instead of PropertyMOdel.PropertyModel has big problems in refactoring. In my cases I did it and the problems solved properly.Also I have override the toString() of my Topic object.
topicDropDown = new DropDownChoice<Topic>("topicOptions", new IModel<Topic>() {
#Override
public Topic getObject() {
return top;
}
#Override
public void setObject(Topic t) {
top = t;
}
#Override
public void detach() {
}
}, new LoadableDetachableModel<List<Topic>>() {
#Override
protected List<Topic> load() {
List<Topic> topics = top.getAllTopics();
return topics;
}
});
I'm struggling with a very basic Wicket issue. I'm trying to query a backend database, but can't get the results to display. Below is the code I'm using. currentQuery and currentResult is correctly updated after submission, but my SearchResults class is never rerendered with the new data in currentResults. I suppose that the results class just doesn't notice that the model has in fact been updated. I've been experimenting with modelChanged, but can't get it to work. I'm a bit new to Wicket, so I'm probably doing something fundamental completely wrong. Any help is much appreciated!
public class SearchPage extends WebPage {
Query currentQuery = new Query();
Result currentResult = new Result();
public SearchPage() {
add(new SearchForm("searchForm", new CompoundPropertyModel<Query>(currentQuery)));
add(new SearchResults("searchResults", new PropertyModel<List<Hit>>(currentResult, "hits")));
}
public void doSearch(Query Query) {
currentResult = getResults(query);
}
public class SearchForm extends Form<Query> {
public SearchForm(String id, CompoundPropertyModel<Query> model) {
super(id, model);
add(new TextField<String>("query"));
}
protected void onSubmit() {
super.onSubmit();
doSearch(currentQuery);
}
}
public class SearchResults extends WebMarkupContainer {
public SearchResults(String id, PropertyModel<List<Hit>> model) {
super(id, model);
add(new ListView<Hit>("hit", model) {
protected void populateItem(ListItem<Hit> item) {
item.add(new Label("column", item.getModelObject().getColumnValue("column")));
}
});
}
}
}
PropertyModel uses reflection to look up the named property on a given target object instance. When you constructed the PropertyModel, you passed it a specific instance of Result, i.e. the new Result() from SearchPage's constructor. The PropertyModel will continue to hold a reference to that same Result instance from render to render of this page, serializing the Result at the end and then deserializing the Result at the start of each new request cycle (page view). The fact that you later change the page's currentResult variable to reference a different Result instance does not affect which Result instance the PropertyModel uses to look up its model value. Your PropertyModel does not care what currentResult later refers to.
There are two possible solutions that I can think of off the top of my head.
Have the PropertyModel read hits from the actual current value of the Page's currentResult variable:
new PropertyModel<List<Hit>>(SearchPage.this, "currentResult.hits")
Use a LoadableDetachableModel to load hits once per request cycle/page view:
new LoadableDetachableModel<List<Hit>>()
{
protected Object load()
{
return getResults(currentQuery);
}
}
Note that a LoadableDetachableModel has to be detached at the end of the request cycle or it will never again call getObject() to recalculate the List<Hit>. That said, since your code shows you'd be using it as the default model of the SearchResults component, the SearchResults component would detach the model for you at the end of the request cycle automatically.
I got it working. This seems to be the offending row:
add(new SearchResults("searchResults", new PropertyModel<List<Hit>>(currentResult, "hits")));
The type of the PropertyModel, i.e. List<Hit>, must have been making the model static. So the only data SearchResults ever saw was the initial object, which was empty.
I changed the line to the below, and updated SearchResult accordingly.
add(new SearchResults("searchResults", new Model<Result>(currentResult, "hits")));
If anyone can explain this further, or feel that I'm incorrect, please comment! In any case, I'm marking my own answer as correct as this solved the problem.