In drop down I get like this. find image attached. Actually in coulmn of "Name" field both 'Name' and 'Description' are displaying as comma(,) separated.
final ComboBoxItem comboBoxItem = new ComboBoxItem("attributeTypeId","Attr. Type");
ListGridField nameField = new ListGridField("name", "Name");
ListGridField descField = new ListGridField("description","Description");
descField.setShowHover(true);
comboBoxItem.setPickListFields(nameField, descField);
comboBoxItem.setPickListWidth(200);
comboBoxItem.setFilterLocally(true);
comboBoxItem.setColSpan(2);
comboBoxItem.setAddUnknownValues(false);
comboBoxItem.setValueField(FieldNames.ID_FIELD);
comboBoxItem.setDisplayField(FieldNames.NAME_FIELD);
comboBoxItem.setAutoFetchData(true);
OptionListDataSource attrTypeds = OptionListDataSource.getInstance(FieldNames.ATTRIBUTE_TYPE_FIELD);
attrTypeds.fetchData(null, new DSCallback() {
#Override
public void execute(final DSResponse response, final Object rawData, final DSRequest request) {
Record[] recList = response.getData();
LinkedHashMap<String, String[]> dataLinkMap = new inkedHashMap<String,String[]>(); //LinkedHashMap<String,
dataLinkMap.put("0", new String[]{"Select",""});
for (Record record : recList) {
String attrId = record.getAttribute(FieldNames.ID_FIELD);
String attrName = record.getAttribute(FieldNames.NAME_FIELD);
String attrDesc = record.getAttribute(FieldNames.DESCRIPTION_FIELD);
dataLinkMap.put(attrId, new String[]{attrName,attrDesc});
}
comboBoxItem.setValueMap(dataLinkMap);
}
});
Screen Shot
Here is some sample code to achieve what I understand you want to achieve:
public class TestCases implements EntryPoint {
public void onModuleLoad() {
DataSource logDS = DataSource.get("yourDSName");
final DynamicForm form = new DynamicForm();
form.setWidth(550);
form.setNumCols(2);
ListGridField nameField = new ListGridField(FieldNames.NAME_FIELD);
ListGridField descriptionField = new ListGridField(FieldNames.NAME_DESCRIPTION);
LinkedHashMap<String,String> hashMap = new LinkedHashMap<String,String>();
hashMap.put("-1", "Select");
ComboBoxItem myItem = new ComboBoxItem();
myItem.setTitle("ComboBox");
myItem.setOptionDataSource(logDS);
myItem.setDisplayField("category");
myItem.setValueField(FieldNames.ID_FIELD);
myItem.setSpecialValues(hashMap);
myItem.setPickListWidth(300);
myItem.setPickListFields(nameField, descriptionField);
form.setItems(myItem);
form.draw();
}
}
Notice:
In order to display various fields, you need to use setPickListFields with the reference to those fields.
You don't need to call fetch() on the DataSource itself. This is done automatically for you when you use DataBound components like ComoBoxItem.
You can add additional empty values using setSpecialValues() without modifying your DSResponse data (which is why you don't need to use fetch() directly).
EDIT
The problem you are having is that the ValueMap, which is just a Map (in other words, just a group of key/value pairs), that you are providing to the ComboBoxItem is not the same as the Record[] object provided directly by the DataSource, which in essence is just a List made of several Maps, each representing a field name and its value. This way, besides the value field, you can provide several fields to the ComboBoxItem for display purposes, like Name and Description, in your particular case.
From looking at the API, it looks to me that you can't provide a Record[] manually to the ComboBoxItem, so either you get the data via DMI (which for me is the easiest) or other method that allows you to modify and return the required response from the server automatically to the ComboBoxItem by using the data binding capabilities, or you stick to showing just the "values" (which is what you are getting right now, but off course you could format the data better).
What I mean with formatting is that if you choose to go with your original approach of using setValueMap(), you need to provide a Map where each entry in the Map is just a value on the ComboBoxItem and its respective display "text", which can be any String combining the values of several other fields, and formatted as desired using String concatenation (for instance, you could make it
nameField + ": " + descriptionField
But this is as good as it gets with this approach.
Now, via a DMI you would need to define the server class that would provide the properly-formatted data in you datasource descriptor (ds.xml file):
<operationBindings>
<operationBinding operationType="fetch" serverMethod="fetchComboBoxData">
<serverObject lookupStyle="new" className="com.myApp.ComboBoxDMI"/>
</operationBinding>
</operationBindings>
And then create the class and method to provide what you need:
public class ComboBoxDMI {
public DSResponse fetchComboBoxData(DSRequest dsRequest) throws Exception {
DSResponse response = dsRequest.execute();
if (response.statusIsSuccess()) {
#SuppressWarnings("unchecked")
List<Map<String, Object>> recList = response.getRecords();
List<Map<String, Object>> comboBoxList = new ArrayList<Map<String,Object>>();
// Add here the new record... for each field in your DataSource, you need to set a Map
// with the key being the field name and the value being the field value. So you need
// 1 Map entry per field. All your Map entries form 1 record, and that's what you add
// to your List of Maps
return constructDSResponse(comboBoxList);
}
return response;
}
private DSResponse constructDSResponse(List<Map<String, Object>> comboBoxList) {
DSResponse response = new DSResponse();
int totalRows = comboBoxList.size();
response.setStartRow(totalRows > 0 ? 1 : 0);
response.setEndRow(totalRows);
response.setTotalRows(totalRows);
response.setData(comboBoxList);
return response;
}
}
Finally, you can follow the original approach I suggest in my original answer, but now you don't need to use the setSpecialValues API, which your version doesn't support.
Related
I am trying to map one object onto another one (Record -> ParsedAddress) with the following code:
public class ParsedAddress extends Address {
private static final Map<Field, Consumer<String>> MAPPINGS = new EnumMap<>(Field.class);
public ParsedAddress(final Record record, final List<Field> order) {
super();
this.mapFields(record, order);
}
private void mapFields(final Record record, final List<Field> order) {
this.setupMapping();
for (final Map.Entry<Field, Consumer<String>> mapping : MAPPINGS.entrySet()) {
final Field field = mapping.getKey();
final String value = record.getField(field, order);
final Consumer<String> setter = mapping.getValue();
setter.accept(value);
}
}
private void setupMapping() {
if (!MAPPINGS.isEmpty()) return;
MAPPINGS.put(SALUTATION, this::setSalutation);
MAPPINGS.put(FIRST_NAME, this::setFirstName);
MAPPINGS.put(SURNAME, this::setSurname);
// etc...
}
}
(Address is a data object that contains all the mapped fields.)
I call the constructor like this:
records.stream()
.map(record -> new ParsedAddress(record, ORDER))
.collect(toUnmodifiableList());
But only the first "record" gets mapped. The result collection contains one ParsedAddress that has all the data (so the logic works alright) and ParsedAddresses that have null fields.
I debugged it and managed to narrow the issue down to the setter.accept(value) line. It works exactly the same whether the constructor is called inside a stream or a loop.
Is it something about the object initialization? But then, why is exactly one object mapped successfully and the rest is not?
EDIT:
The Record class only contains the data to be mapped. Here's the getField method:
public String getField(final Field field, final List<Field> order) {
final int index = order.indexOf(field);
return index == -1 ? null : this.data.get(index);
}
The problem here is that the MAPPINGS map is a lazy-loaded static map yet the this keyword is not.
This results in a map that is filled-in exactly once but with references to public setters of the very first object that reached it (the one that lazy-loaded the map).
So every consumer in MAPPINGS is a public setter for the very same object (the one that lazy-loaded the map).
That was fun!
I have facade interface where users can ask for information about lets say Engineers. That information should be transferred as JSON of which we made a DTO for. Now keep in mind that I have multiple datasources that can provide an item to this list of DTO.
So I believe right now that I can use Decorative Pattern by adding handler of the datasource to the myEngineerListDTO of type List<EngineerDTO>. So by that I mean all the datasources have the same DTO.
This picture below shows that VerticalScrollbar and HorizontalScrollBar have different behaviours added. Which means they add behaviour to the WindowDecorator interface.
My question, does my situation fit the decorator pattern? Do I specifically need to add a behaviour to use this pattern? And is there another pattern that does fit my situation? I have already considered Chain of Responsibility pattern, but because I don't need to terminate my chain on any given moment, i thought maybe Decorator pattern would be better.
Edit:
My end result should be: List<EngineersDTO> from all datasources. The reason I want to add this pattern is so that I can easily add another datasource behind the rest of the "pipeline". This datasource, just like the others, will have addEngineersDTOToList method.
To further illustrate on how you can Chain-of-responsibility pattern I put together a small example. I believe you should be able to adapt this solution to suit the needs of your real world problem.
Problem Space
We have an unknown set of user requests which contain the name of properties to be retrieved. There are multiple datasources which each have varying amounts of properties. We want to search through all possible data sources until all of the properties from the request have been discovered. Some data types and data sources might look like bellow (note I am using Lombok for brevity):
#lombok.Data
class FooBarData {
private final String foo;
private final String bar;
}
#lombok.Data
class FizzBuzzData {
private final String fizz;
private final String buzz;
}
class FooBarService {
public FooBarData invoke() {
System.out.println("This is an expensive FooBar call");
return new FooBarData("FOO", "BAR");
}
}
class FizzBuzzService {
public FizzBuzzData invoke() {
System.out.println("This is an expensive FizzBuzz call");
return new FizzBuzzData("FIZZ", "BUZZ");
}
}
Our end user might require multiple ways to resolve the data. The following could be a valid user input and expected response:
// Input
"foobar", "foo", "fizz"
// Output
{
"foobar" : {
"foo" : "FOO",
"bar" : "BAR"
},
"foo" : "FOO",
"fizz" : "FIZZ"
}
A basic interface and simple concrete implementation for our property resolver might look like bellow:
interface PropertyResolver {
Map<String, Object> resolve(List<String> properties);
}
class UnknownResolver implements PropertyResolver {
#Override
public Map<String, Object> resolve(List<String> properties) {
Map<String, Object> result = new HashMap<>();
for (String property : properties) {
result.put(property, "Unknown");
}
return result;
}
}
Solution Space
Rather than using a normal "Decorator pattern", a better solution may be a "Chain-of-responsibility pattern". This pattern is similar to the decorator pattern, however, each link in the chain is allowed to either work on the item, ignore the item, or end the execution. This is helpful for deciding if a call needs to be made, or terminating the chain if the work is complete for the request. Another difference from the decorator pattern is that resolve will not be overriden by each of the concrete classes; our abstract class can call out to the sub class when required using abstract methods.
Back to the problem at hand... For each resolver we need two components. A way to fetch data from our remote service, and a way to extract all the required properties from the data retrieved. For fetching the data we can provide an abstract method. For extracting a property from the fetched data we can make a small interface and maintain a list of these extractors seeing as multiple properties can be pulled from a single piece of data:
interface PropertyExtractor<Data> {
Object extract(Data data);
}
abstract class PropertyResolverChain<Data> implements PropertyResolver {
private final Map<String, PropertyExtractor<Data>> extractors = new HashMap<>();
private final PropertyResolver successor;
protected PropertyResolverChain(PropertyResolver successor) {
this.successor = successor;
}
protected abstract Data getData();
protected final void setBinding(String property, PropertyExtractor<Data> extractor) {
extractors.put(property, extractor);
}
#Override
public Map<String, Object> resolve(List<String> properties) {
...
}
}
The basic idea for the resolve method is to first evaluate which properties can be fulfilled by this PropertyResolver instance. If there are eligible properties then we will fetch the data using getData. For each eligible property we extract the property value and add it to a result map. Each property which cannot be resolved, the successor will be requested to be resolve that property. If all properties are resolved the chain of execution will end.
#Override
public Map<String, Object> resolve(List<String> properties) {
Map<String, Object> result = new HashMap<>();
List<String> eligibleProperties = new ArrayList<>(properties);
eligibleProperties.retainAll(extractors.keySet());
if (!eligibleProperties.isEmpty()) {
Data data = getData();
for (String property : eligibleProperties) {
result.put(property, extractors.get(property).extract(data));
}
}
List<String> remainingProperties = new ArrayList<>(properties);
remainingProperties.removeAll(eligibleProperties);
if (!remainingProperties.isEmpty()) {
result.putAll(successor.resolve(remainingProperties));
}
return result;
}
Implementing Resolvers
When we go to implement a concrete class for PropertyResolverChain we will need to implement the getData method and also bind PropertyExtractor instances. These bindings can act as an adapter for the data returned by each service. This data can follow the same structure as the data returned by the service, or have a custom schema. Using the FooBarService from earlier as an example, our class could be implemented like bellow (note that we can have many bindings which result in the same data being returned).
class FooBarResolver extends PropertyResolverChain<FooBarData> {
private final FooBarService remoteService;
FooBarResolver(PropertyResolver successor, FooBarService remoteService) {
super(successor);
this.remoteService = remoteService;
// return the whole object
setBinding("foobar", data -> data);
// accept different spellings
setBinding("foo", data -> data.getFoo());
setBinding("bar", data -> data.getBar());
setBinding("FOO", data -> data.getFoo());
setBinding("__bar", data -> data.getBar());
// create new properties all together!!
setBinding("barfoo", data -> data.getBar() + data.getFoo());
}
#Override
protected FooBarData getData() {
return remoteService.invoke();
}
}
Example Usage
Putting it all together, we can invoke the Resolver chain as shown bellow. We can observe that the expensive getData method call is only performed once per Resolver only if the property is bound to the resolver, and that the user gets only the exact fields which they require:
PropertyResolver resolver =
new FizzBuzzResolver(
new FooBarResolver(
new UnknownResolver(),
new FooBarService()),
new FizzBuzzService());
Map<String, Object> result = resolver.resolve(Arrays.asList(
"foobar", "foo", "__bar", "barfoo", "invalid", "fizz"));
ObjectMapper mapper = new ObjectMapper();
mapper.enable(SerializationFeature.INDENT_OUTPUT);
System.out.println(mapper
.writerWithDefaultPrettyPrinter()
.writeValueAsString(result));
Output
This is an expensive FizzBuzz call
This is an expensive FooBar call
{
"foobar" : {
"foo" : "FOO",
"bar" : "BAR"
},
"__bar" : "BAR",
"barfoo" : "BARFOO",
"foo" : "FOO",
"invalid" : "Unknown",
"fizz" : "FIZZ"
}
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.
I need strict compliance with the order of the elements in my xml document. If I use XmlHttpContent serializer to form xml content, fields sort alphabetically.
Is there any way to specify explicitly order of the elements in xml? Or are there other ways to create and post http requests with the xml body?
I know this answer isn't ideal but I recently came across this issue when trying to use the http client library for serialisation to xml. The solution I've found that works is to have my DTO classes provide a method to convert them into a sorted map of some kind.
In my case this is an ImmutableMap<String, Object> as I'm also using Guava but any map with controllable order will do. The basic idea is to work with the java objects to construct your data but then when the time comes to serialise them you serialise the map instead.
public interface OrderedXml {
ImmutableMap<String, Object> toOrderedMap();
}
public class Parent implements OrderedXml {
#Key("First") String first;
#Key("Second") String second;
#Key("Child") Child third;
#Override
public ImmutableMap<String, Object> toOrderedMap() {
return ImmutableMap.of(
// the order of elements in this map will be the order they are serialised
"First", first,
"Second", second,
"Child", third.toOrderedMap()
);
}
}
public class Child implements OrderedXml {
#Key("#param1") String param1;
#Key("#param2") String param2;
#Key("text()") String value;
#Override
public ImmutableMap<String, Object> toOrderedMap() {
return ImmutableMap.of(
// the same goes for attributes, these will appear in this order
"#param1", param1,
"#param2", param2,
"text()", value
);
}
}
public class Main {
public static void main(String[] args) {
// make the objects
Parent parent = new Parent();
parent.first = "Hello";
parent.second = "World";
parent.child = new Child();
parent.child.param1 = "p1";
parent.child.param2 = "p2";
parent.child.value = "This is a child";
// serialise the object to xml
String xml = new XmlNamespaceDictionary()
.toStringOf("Parent", parent.toOrderedXml()); // the important part
System.out.println(xml); // should have the correct order
}
}
I know this solution isn't ideal but at least you can reuse the toOrderedXml to make a nice toString :-).
I'm rather new to Play Framework so I hope this is intelligible.
How can I tell play to map a form element to an Object field in the Form's class?
I have a form with a select dropdown of names of objects from my ORM. The values of the dropdown items are the ID field of the ORM objects.
The form object on the Java side has a field with the type of the ORM object, and a setter taking a string and translating it to the object, but on form submission I only get a form error "Invalid Value" indicating the translation is not taking place at all.
My template has a form component:
#helper.select(
createAccountForm("industry"),
helper.options(industries)
)
Where industries is defined in the template constructor by : industries: Map[String, String]
and consists of ID strings to User-Readable names.
My controller defines the class:
public static class CreateAccountForm {
public String name;
public Industry industry;
public void setIndustry(String industryId) {
this.industry = Industry.getIndustry(Integer.parseInt(industryId));
}
}
EDIT: I was doing the setter in the class because this answer indicated to do so, but that didn't work.
EDIT2:
Turns out the setter method was totally not the way to go for this. After banging my head a bit on trying to get an annotation working, I noticed the Formatters.SimpleFormatter and tried that out. It worked, though I don't understand why the extra block around it is necessary.
Global.java:
public class Global extends GlobalSettings {
// Yes, this block is necessary; no, I don't know why.
{
Formatters.register(Industry.class, new Formatters.SimpleFormatter<Industry>() {
#Override
public Industry parse(String industryId, Locale locale) throws ParseException {
return Industry.getIndustry(Integer.parseInt(industryId));
}
#Override
public String print(Industry industry, Locale locale) {
return industry.name;
}
});
}
}
Play is binding the form to an object for you when you use it like described in the documentation: https://github.com/playframework/Play20/wiki/JavaForms
So your controller should look like:
Form<models.Task> taskForm = form(models.Task.class).bindFromRequest();
if (taskForm.hasErrors()) {
return badRequest(views.html.tasks.create.render(taskForm));
}
Task task = taskForm.get();
The task object can have a Priority options list. And you use it in the form (view) like:
#select(editForm("priority.id"), options(Task.priorities), 'class -> "input-xlarge", '_label -> Messages("priority"), '_default -> Messages("make.choice"), 'showConstraints -> false, '_help -> "")
Notice that I am using priorities.id to tell play that a chosen value should be binded by a priority ID. And of course getting the priorities of the Tasks:
public static Map<String, String> priorities() {
LinkedHashMap<String, String> prioritiesList = new LinkedHashMap<String, String>();
List<Priority> priorities = Priority.getPrioritiesForTask("task");
for (Priority orderPrio : priorities) {
prioritiesList.put(orderPrio.getId().toString(), orderPrio.getDescription());
}
return prioritiesList;
}