Code:
realisation MyContentProvider {
Object [] getAssociatedObjects(Object object) { //get children
if(object==domainModel) {
return domainModel.getAllCustomers(); //first idea
//or
return domainModel.values(); //plus using a filter to filter out customers
//or
return (List)domainModel.get("customers"); //silly
}
else
return new Object [0];
}
}
Plain and simple. But now you can use List, Map, Set, Collection or more preferable something like DomainModel, DatabaseModel or ResultSet. It is a matter of the content provider not of the view anymore. The freedom is yours.
First, your syntax is confusing. Where does this "realisation" thing come from and what is it?
And who's going to call the getAssociatedObjects() method?
Is it the View?
In that case you seem to have decided that a pure object array is the right thing for the View and not a Collection which I assumed you meant earlier?
If the ContentProvider is in fact the generic domain model API as seen from the View, that's fine. I have a similar API which hides any kind of data source and they can of course use any collection type they want.
But I don't see that your solution is any more generic or very different from using:
Code:
List getAssociatedObjects(Object object)
Personally I prefer to use the List instead of Object[] for reasons like flexibility, easy sorting and filtering etc. But it really is no big deal, I can of course convert the object array to a List inside the View anyway.
Easy isn't it? No talk about a List or a Map. Just what it does. Adapt the domain model to the viewer. Plain and simple. Now you can add a sorter and a filter and you have a powerfull viewer enabling you to build powerfull views / GUI applications.
Well, no easier than my solution, just a tad different. It seems to me you convert any collection to Object[] when submitting your domain data to the View.
Please correct me if I'm wrong, but it seems to me we were talking a bit past each other and we don't really disagree that much on this issue.
Code:
realisation MyLabelProvider {
String getText(Object object) {
if(object instanceof Model)
return "Domain Model";
else if(object instanceof CustomerRepository)
return "Customers";
else if(object instanceof OfferRepository)
return "Offers"
else if(object instanceof Customer)
return ((Customer)object).getName();
else if(object instanceof Offer)
return ((Offer)object).getDescription();
else
return null;
}
This I do not like! :-)
I would not have a labelprovider that is potentially tied to all my domain objects. Besides, using a Provider for simply setting a label seems like overkill. And you need labels for your Customer fields too. How do you handle those?
I prefer having all labels and some other config info for each domain object in separate classes.
In my framework I use reflection to get all fields from a domain model class using what I call a BeanPicker:
Code:
BeanPicker customerConfig = new BeanPicker(Customer.class);
That's basically all. The BeanPicker is then submitted to the View that displays all its properties and using the Customer class name as a label.
Code:
View customerTreeView = new TreeView(customerConfig);
View customerTableView = new TableView(customerConfig);
But since using reflection often means getting more of the class's properties than I want to display and the property names are probably not what I want to use for field labels etc, I can submit an array of mappings in the constructor, telling the right labels to use for each property, and at the same time specify their order and which one to include and exclude. Like this:
Code:
String[][] propertyLables = {
{ "name" , "Name" },
{ "id" , "Identifier" },
{ "address" , "Address" },
Any properties of the class not included here will be silently ignored as will any included but not recognised by the reflection mechanism.
Then I do:
Code:
BeanPicker customerConfig = new BeanPicker(Customer.class, propertyLabels);
For the labels that you mention I have:
Code:
customerConfig.setSingularLabel("Customer");
customerConfig.setPluralLabel("Customers");
The BeanPicker has a few other methods like setting which property is editable etc.
/Ragnar
Reply With Quote
Originally Posted by pdbruycker
