How to bind enum values with SWT Combo - eclipse-plugin

I want to bind enum values to SWT Combo.
Lets says I am having following code snippet
Person model class
public class Person {
private String name;
private Gender gender;
public setGender(Gender gender) {
this.gender = gender;
}
public Gender getGender() {
return gender;
}
}
Gender enum
public enum Gender {
MALE("male"), FEMALE("female");
}
Binding between combo selection and gender property of Person.
IObservableValue<?> observeWidget = WidgetProperties.selection().observe(combo);
IObservableValue<?> observeModel = PojoProperties.value(person.getClass(), "gender").observe(person);
Binding between combo values and enum Gender.
IObservableList<?> observeWidget = WidgetProperties.items().observe(combo);
IObservableList<?> observableList = PojoProperties.list(enumGender.getClass(), "???? property name ????").observe(enumGender);
How i can achive above binding ??
I want to bind Gender.values() (this method default in every enum and return an array of string) with SWT combo.
For binding, we must provide property name in API call, but enum does not contain any such property.
I know we can achieve this using ComboBoxViewer like
comboViwer.setInput(Gender.values()).
but I want to do bind any enum with combo.

Did you check the snippet Snippet034:
https://github.com/eclipse/eclipse.platform.ui/blob/master/examples/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet034ComboViewerAndEnum.java
Basing on the version you are using maybe you have to adapt the call to "bindValue" passing less/more parameters

Related

Is it possible to serialize a classname similar to a property

I understand I can use code similar to the below to change the property name from Name to name when it is serialized but I also want to change the object name when it is serialized and returned using return something like Ok(myobj);
But, is it possible to do something similar for the class as below so it is serialized as person and not Person. I've looked at JsonObject but can't see anything on there.
[JsonObject(PropertyName="person")]
public class Person
{
[JsonProperty(PropertyName = "name")]
public String Name { get; set; }
}
If you just want your class name to start with a lowercase letter, you can do this:
[JsonObject(NamingStrategyType = typeof(CamelCaseNamingStrategy))]
public class Person
{
}
This would set the first letter of your class name to lowercase since it uses CamelCaseNamingStategy, you can also create your own custom naming strategy to fit your needs, implementation of existing naming stategies can be found here: (https://github.com/JamesNK/Newtonsoft.Json/tree/master/Src/Newtonsoft.Json/Serialization)
You will need another wrapper object to have like that. You can use:
return Ok(new{
Person = myobj
});

Populating a single Listview with multiple custom array of objects in Xamarin

I am new to xamarin/Mobile development. I got a task to create a single listview which should populate the objects of two different classes using xamarin.forms.
`Class A
{
string PendingRequestID;
string PendingRequestStatus;
string PendingRequest;
}
Class B
{
String CompletedRequestId;
String ApprovedByUsername;
DateTime CompletedTime
}
`
above are the two different entities and I need to populate the list of objects of both in single list view. Each object is having its own separate UI layout.
How can i specify multiple ItemSource in a ListView in xamarin.forms?
Please help me.
Just create a property of type ObservableCollection<object> for ItemsSource on ListView and use a data template selector in order to provide item-type based template(s) to ListView.
An example can be found here
EDIT - 1 : Sample code
class MyDataTemplateSelector : Xamarin.Forms.DataTemplateSelector
{
public MyDataTemplateSelector()
{
// Retain instances!
this._typeADataTemplate = new DataTemplate(typeof(TypeAViewCell));
this._typeBDataTemplate = new DataTemplate(typeof(TypeBViewCell));
}
protected override DataTemplate OnSelectTemplate(object item, BindableObject container)
{
if (item == null)
return null;
return (item is A) ? this._typeADataTemplate : this._typeBDataTemplate;
}
private readonly DataTemplate _typeADataTemplate;
private readonly DataTemplate _typeBDataTemplate;
}
You can't assign multiple types for ItemSource. Therefore, one way is to use a third class as a base class and then derive your A and B from it. Then use this C type as ItemSource.
Class C{
...
}
Class A : C
{
string PendingRequestID;
string PendingRequestStatus;
string PendingRequest;
}
Class B : C
{
String CompletedRequestId;
String ApprovedByUsername;
DateTime CompletedTime
}
Note that you will then need to check for the right subtype during runtime whenever you click on an Item in the list.
Hope it helps!

How to easily access widely different subsets of fields of related objects/DB tables?

Imagine we have a number of related objects (equivalently DB tables), for example:
public class Person {
private String name;
private Date birthday;
private int height;
private Job job;
private House house;
..
}
public class Job {
private String company;
private int salary;
..
}
public class House {
private Address address;
private int age;
private int numRooms;
..
}
public class Address {
private String town;
private String street;
..
}
How to best design a system for easily defining and accessing widely varying subsets of data on these objects/tables? Design patterns, pros and cons, are very welcome. I'm using Java, but this is a more general problem.
For example, I want to easily say:
I'd like some object with (Person.name, Person.height, Job.company, Address.street)
I'd like some object with (Job.company, House.numRooms, Address.town)
Etc.
Other assumptions:
We can assume that we're always getting a known structure of objects on the input, e.g. a Person with its Job, House, and Address.
The resulting object doesn't necessarily need to know the names of the fields it was constructed from, i.e. for subset defined as (Person.name, Person.height, Job.company, Address.street) it can be the array of Objects {"Joe Doe", 180, "ACompany Inc.", "Main Street"}.
The object/table hierarchy is complex, so there are hundreds of data fields.
There may be hundreds of subsets that need to be defined.
A minority of fields to obtain may be computed from actual fields, e.g. I may want to get a person's age, computed as (now().getYear() - Person.birtday.getYear()).
Here are some options I see:
A SQL view for each subset.
Minuses:
They will be almost the same for similar subsets. This is OK just for field names, but not great for the joins part, which could ideally be refactored out to a common place.
Less testable than a solution in code.
Using a DTO assembler, e.g. http://www.genericdtoassembler.org/
This could be used to flatten the complex structure of input objects into a single DTO.
Minuses:
I'm not sure how I'd then proceed to easily define subsets of fields on this DTO. Perhaps if I could somehow set the ones irrelevant to the current subset to null? Not sure how.
Not sure if I can do computed fields easily in this way.
A custom mapper I came up with.
Relevant code:
// The enum has a value for each field in the Person objects hierarchy
// that we may be interested in.
public enum DataField {
PERSON_NAME(new PersonNameExtractor()),
..
PERSON_AGE(new PersonAgeExtractor()),
..
COMPANY(new CompanyExtractor()),
..
}
// This is the container for field-value pairs from a given instance of
// the object hierarchy.
public class Vector {
private Map<DataField, Object> fields;
..
}
// Extractors know how to get the value for a given DataField
// from the object hierarchy. There's one extractor per each field.
public interface Extractor<T> {
public T extract(Person person);
}
public class PersonNameExtractor implements Extractor<String> {
public String extract(Person person) {
return person.getName();
}
}
public class PersonAgeExtractor implements Extractor<Integer> {
public int extract(Person person) {
return now().getYear() - person.getBirthday().getYear();
}
}
public class CompanyExtractor implements Extractor<String> {
public String extract(Person person) {
return person.getJob().getCompany();
}
}
// Building the Vector using all the fields from the DataField enum
// and the extractors.
public class FullVectorBuilder {
public Vector buildVector(Person person) {
Vector vector = new Vector();
for (DataField field : DataField.values()) {
vector.addField(field, field.getExtractor().extract(person));
}
return vector;
}
}
// Definition of a subset of fields on the Vector.
public interface Selector {
public List<DataField> getFields();
}
public class SampleSubsetSelector implements Selector {
private List<DataField> fields = ImmutableList.of(PERSON_NAME, COMPANY);
...
}
// Finally, a builder for the subset Vector, choosing only
// fields pointed to by the selector.
public class SubsetVectorBuilder {
public Vector buildSubsetVector(Vector fullVector, Selector selector) {
Vector subsetVector = new Vector();
for (DataField field : selector.getFields()) {
subsetVector.addField(field, fullVector.getValue(field));
}
return subsetVector;
}
}
Minuses:
Need to create a tiny Extractor class for each of hundreds of data fields.
This is a custom solution that I came up with, seems to work and I like it, but I feel this problem must have been encountered and solved before, likely in a better way.. Has it?
Edit
Each object knows how to turn itself into a Map of fields, keyed on an enum of all fields.
E.g.
public enum DataField {
PERSON_NAME,
..
PERSON_AGE,
..
COMPANY,
..
}
public class Person {
private String name;
private Date birthday;
private int height;
private Job job;
private House house;
..
public Map<DataField, Object> toMap() {
return ImmutableMap
.add(DataField.PERSON_NAME, name)
.add(DataField.BIRTHDAY, birthday)
.add(DataField.HEIGHT, height)
.add(DataField.AGE, now().getYear() - birthday.getYear())
.build();
}
}
Then, I could build a Vector combining all the Maps, and select subsets from it like in 3.
Minuses:
Enum name clashes, e.g. if Job has an Address and House has an Address, then I want to be able to specify a subset taking street name of both. But how do I then define the toMap() method in the Address class?
No obvious place to put code doing computed fields requiring data from more than one object, e.g. physical distance from Address of House to Address of Company.
Many thanks!
Over in-memory object mapping in the application, I would favor database processing of the data for better performance. Views, or more elaborate OLAP/datawarehouse tooling could do the trick. If the calculated fields remain basic, as in "age = now - birth", I see nothing wrong with having that logic in the DB.
On the code side, given the large number of DTOs you have to deal with, you could use classless dynamic (available in some JVM languages) or JSON objects. The idea is that when a data structure changes, you only need to modify the DB and the UI, saving you the cost of changing a whole bunch of classes in between.

Should I have both text and value in my model for a property that is selected from dropdownlist

In ASP.NET MVC application I have a model named CarSearchCriteria:
public class CarSearchCriteria{
public int CarMake {get;set;} // This is selected from a dropdownlist
public int YearOfFirstReg {get;set;}
public string ModelVariant {get;set}
}
I have two views - one for editing and the other one for viewing. In the editing view for the CarMake property I can do the following. I know I could have used DropDownListFor but didn't want to mess with SelectList for the time being:
<select name="CarMake">
<option value="1">BMW</option>
<option value="2">Mercedes</option>
<option value="3">Toyota</option>
</select>
So the model binding mechanism will easily bind the selected value to the appropriate model property. But what about the reading mode. I can't show 1s or 2s. I need to show BMW, Mercedes and so on. My question is what is the preferred way, do I have to have a property name that holds the actual textual information, something like CarMakeText?
You could have both the identifier (which you currently have) as well as the Make object itself. The latter would never need to be accessed when building the model, but can be accessed when reading the model. A lazy-loaded read-only property often works well for that. Something like this:
public int CarMakeID { get; set; }
public Make CarMake
{
get
{
if (CarMakeID == default(int))
return null;
// fetch the Make from data and return it
}
}
Naturally, this depends a lot on what a Make actually is and where you get it. If there's just some in-memory list somewhere then that should work fine. If fetching an instance of a Make is a little more of an operation (say, fetching from a database) then maybe some in-object caching would be in order in case you need to access it more than once:
public int CarMakeID { get; set; }
private Make _carMake;
public Make CarMake
{
get
{
if (CarMakeID == default(int))
return null;
if (_carMake == null)
// fetch the Make from data and save it to _carMake
return _carMake;
}
}
David's solution is just fine but for some reason I find my own solution to better fit my needs and besides that I find it more elegant. So basically what I do is I create a class that holds the textual descriptions of all the properties that keep just ID. For example, I have the following model:
public class EmployeeModel{
public int EmployeeID {get;set;}
public string FullName {get;set}
*public int DepartmentID {get;set}
*public int SpecialityID {get;set;}
public int Age {get;set;}
}
The properties marked with asterisk are the properties that keep ids of possible many predefined options and when showing we're supposed to show the actual descriptions, not the number representations. So for this purpose, we create a separate class:
public class EmployeeTextValues{
public string DepartmentName {get;set;}
public string SpecialityName {get;set;}
}
And then I just add this class as a property to my model:
public EmployeeTextValues TextValues {get;set;}
After that, it's quite easy to access it from anywhere, including Razor.
P.S. I'm sure that a lot of people will tend to do the following before initializing this property:
Employee emp=new Employee;
emp.Age=25;
emp.TextValues.DepartmentName="Engineering";// Don't do this
If you try to access or set Textvalues.Someproperty you'll get Object reference not set to an instance of an object. So do not forget to set TextValues first to some initialized object. Just a kind reminder, that's all.

VS2010's "Public Property <PropertyName> As <DataType> vs. Public var

In VS2008, I used to type
Public Property <PropName> As <dataType>
and hit the Enter key and the IDE editor would automatically expand it out to a full blown property block.
Now, from what I understand, a new feature of 2010 is that the compiler automatically "expands" the short syntax above into the same IL code that you would get with the full property GET AND SET sub methods that were are accustomed to seeing before in the editor.
But functionality, how the heck is this any different than just having a Public class level variable? If the only diff is what it compiles to and if otehrwise there is no functional difference, isn't the new way less efficient than the old since it involves more code than just having a class level memory variable?
Public <Variable> as <DataType>
I thought that if you weren't going to have code behind your properties that they were essentially the same. I guess the diffrenece is that they just added the keyword "Property" but functionality, their is no diff, eh?
It makes little difference in this particular case, but I never use Public data members - anything that needs exposing outside the class is always done with properties. This means a little more work when declaring them, but when later on you wish that you had a property / accessor methods because you need to implement some code, it's a lot easier knowing that everywhere else in the code is already using your property...
Before someone pulls me up on this, no - it's not the same anyhow... You could manipulate a public member using a reference for instance...
This heavily ties into why properties are useful. They provide a level of isolation between the class implementation and the client code that uses it. When you use a public field, you cannot easily refactor the way the field behaves, the client code references it directly. Changing the field to a property for example requires recompiling all client code that uses it.
The usefulness of an automatic property is that it doesn't force you to decide up front that a field may need to be refactored some day. You can postpone the decision and change it from an automatic property to an explicit property with custom behavior any time you like. Without having to make any changes in the client code.
The JIT compiler ensures that an automatic property is just as efficient as a field, it inlines the accessor method call. The new automatic property syntax makes it just as efficient on your wrists as a public field. This is a complete win-win, it just doesn't make any sense anymore to ever use a public field again.
I am not sure, if I understand your question correctly.
But the need of a public class level variable vs property is already discussed here.
EDIT: Also, the IDE/Compiler makes it easy for you to reduce the code, if you are simply doing get/set
e.g.
public string Name { get; set; }, which doesn't require you to declare a backing field.
But then,you will have to access this member (even inside the class) using the property. Because, the compiler generates a backing field for you & the name of it is unknown.
One other difference is that properties are accessed from other controls such as DataGridView, that can read public property values but not variables.
The major difference between Auto-Implemented Properties (VB) and public Fields are interface definitions.
Codes that are using your class with Auto-Implemented Properties does not need to change if in the future you decide to add logic to the property, whereas if you're using fields you will have to modify the interface definition to a property.
So Auto-Implemented Properties uses the simple syntax of a public Field (without the full blown property declaration) but with the flexibility of a property.
A little bit of example:
Current code (C#):
class PersonA {
public int Age;
public int BirthYear;
}
class PersonB {
public int Age { get; set; }
public int BirthYear { get; set; }
}
Usage:
var john = new PersonA { Age = 30, BirthYear = 1980 };
var jane = new PersonB { Age = 20, BirthYear = 1990 };
If in the future you decide to scrap Age setter and derive the value from BirthYear, you can easily update your class without breaking any of the current client code.
class PersonA {
public int Age { get { return Date.Now.Year - BirthYear; }; set { } };
public int BirthYear;
}
class PersonB {
public int Age { get { return Date.Now.Year - BirthYear; }; set { } };
public int BirthYear { get; set; }
}
Usage:
var john = new PersonA { Age = 30, BirthYear = 1980 }; // broken when not recompiled
var jane = new PersonB { Age = 20, BirthYear = 1990 };