Let's take two Core Data entities, set up as follows:
Entity A: Car
Attributes:
year
model
Relationships:
manufacturer (<<-> Manufacturer)
Entity B: Manufacturer
Attributes:
name
country
Relationships:
cars (<->> Car)
Now, what I want to do is bind the display to an NSTableView where we have the model of the car in one column, followed by the manufacturer, followed by the year. Binding the model and year are no problem, but if I bind the relationship to a column in the table, I get the text of a relationship fault error in each cell in that column instead of anything I'm looking for. How can I play with the binding to allow me to display the proper manufacturer name associated with the car?
Extending the question a bit further, how could I set up another table view to display, say, other Car entries with the same manufacturer relationship?
A bit more information about how you have it set up currently would be helpful. You should be able to bind to your Array Controller in exactly the same fashion as your other attributes, with the same binding and controller key. Just use the full key path manufacturer.name for the model key path.
For a to-many relationship, you use two array controllers. Set up the 'master' array controller to prepare its own content from your Core Data Manufacturer class (in Entity mode). Then, you create a secondary, 'detail' array controller. Leave the detail array controller in Class mode (with the default NSMutableDictionary class), and bind its content set to your master array controller, with the controller key set to selection and the model key path to cars.
Many many tutorials exist out there that do exactly this. I highly recommend running through one or two; I found this MacResearch.org tutorial particularly helpful. The entire series is great.
Related
Can anyone advise on the best way to create a UI for establishing Many-to-Many relationships ?
Lets use an example from a previous question List <<-->> Patient.
I can create two separate Table Views, one for Lists and another for Patients which will allow the user to create Lists and Patients using two separately created Array Controllers (Lists and Patients), one linked to the List entity and other linked to the Patient entity.
Now I would like to be able to add/remove Patients from a List by creating an Table View that shows only Patients in the selected List. To do this I create a Array Controller (ListPatients) linked to the entity Patient with a Content Set binding to Lists.selection.patients.
Now things stop working nicely from here on....
If I bind a button to the ListPatients.add method then a NEW Patient gets created - there seems to be no way to simply add a NEW relationship between an existing Patient and the List.
Ideally what I would like to be able to do is to have a drop down list to select the Patient from.
Does anyone have any suggestions as to how best to do this without needing to create a new entity to represent this relationship.
What you need is a swapping Master-Detail view where either the List table or the Patient table is the Master or the Detail at any particular time.
When the List is the Master view, selecting a row will cause the Detail view to display all the Patient objects in the rowList.patients relationship. When the Patient is the Master view, selecting a row will cause the Detail view to display all the List objects in the rowPatient.lists relationship.
You really do want to break up the UI so the users always have a clear idea what the relationship is between the two tables. I would recommend a set of four tables, two each for each Master-Detail setup. That way, the user will also understand what they are looking at.
That will also make it easy to add new objects. Just put an add new button under the detail table and the user will understand that clicking it will add a new object to the relationship of the object selected in the Master view.
I know it could be bad to use domain models as view models. If my domain model has a property named IsAdmin and I have a Create controller action to create users, someone could alter my form and get it to POST a IsAdmin=true form value, even if I did not expose such a text field in my view. If I'm using model binding then when I committed my domain model, that person would now be an admin. So the solution becomes exposing just the properties I need in the view model and using a tool like AutoMapper to map the property values of my returning view model object to that of my domain model object. But I read that the bind attribute on a class can be used to instruct the Model Binder which properties it should and shouldn't bind. So what really is the reason for making two separate classes (domain model and view model) that essential represent the same thing and then incure overhead in mapping them? Is it more a code organization issue and if so, how am I benefiting?
EDIT
One of the most important reasons I've come across for a View Model that's separate from the Domain Model is the need to implement the MVVM pattern (based on Martin Fowler's PM pattern) for managing complex UIs.
I have found that while my domain model gets me 85% of the way to having the fields I want, it has never covered 100% of the values I want on my view. Especially when it comes to permissions and whether or not a user should have access to certain portions of the view.
The design concept I attempt to follow is to have as little logic in my views as possible. This means I have fields in my view model like "CanViewThisField" or "CanEditThisField." When I first started with MVC I would have my domain model be my view model and I was always running into the scenario where I needed just one or two more fields to make my view less cluttered. I've since gone the View Model/Model Builder route and it has worked wonderfully for me. I don't battle my code any longer but am able to enhance my view model as I need to without affecting the domain model.
Another good reason to have a ViewModel is paging large sets of data. You could pass the view an array of Person ( Person[] ) but metadata such as the number of pages, the number of the current page, the size of the page would not belong on the Person class.
Therefore a PersonListViewModel would solve this issue.
A ViewModel holds only those members which are required by the View. They can usually be thought of as a simplification or a "flattening" of the underlying domain model.
Think of them like this:
ViewModel: this is the data that is appropriate to render on this
view
Domain model: this is all the information my application needs
about this entity in order to perform all it's functionality
For example, my Order class has a member called Customer which is a composition association, that is, my Order has a Customer. This Customer object has members such as Firstname, Lastname, etc... But how would I show this on a "details" view of the order or a list of Orders and the Customers who placed them?
Well, using a ViewModel I can have an OrderListItemViewModel which has a CustomerName member and I can map the combination of Firstname and Lastname from the Customer object to this. This can be done manually, or much preferably using Automapper or similar.
Using this approach, you can have multiple Order ViewModels that are specific to different views, e.g. the Order list view might render the customer name in a different way to the Order details view.
Another advantage of ViewModels is that you can cut down on extraneous data not required of the underlying domain object on a view, e.g. if I'm viewing a list of orders, do I really want to see all the customer's contact information, billing details, etc...? I guess that depends on the purpose of the list but, probably not.
Sometimes you need to display the data in a specific manner (ie, displaying a date in the format mm/dd/yyyy vs. yyyy/mm/dd) and often it is easier to make this property in the view and not in the domain model, where you would (or should) have a mapping to a column in your db.
you need to remember
that your domain model classes are only used internally; that is, they are never sent to the
client. That’s what your service model types (View Model types) are used for—they represent the data that will be going back and forth between the client and your service.
I have having a little trouble wrapping my head around the design pattern for MVC when the data type of the model property is very different than what I wish to display in a form. I am unsure of where the logic should go.
Realizing that I am not really sure how to ask the question I think I will explain it as a concrete example.
I have a table of Invoices with a second table containing the InvoiceDetails. Each of the InvoiceDetail items has an owner who is responsible for approving the charge. A given invoice has one or more people that will eventually sign off on all the detail rows so the invoice can be approved. The website is being built to provide the approval functionality.
In the database I am storing the employee id of the person who approved the line item. This schema provides me a model with a String property for the Approved column.
However, on the website I wish to provide a CheckBox for the employee to click to indicate they approve the line item.
I guess my question is this -- how do I handle this? The Model being passed to the View has a String property but the form value being passed back to the Controller will be of the CheckBox type. I see two possible ways...
1) Create a new Model object to represent the form fields...say something like FormInvoiceDetails...and have the business logic query the database and then convert the results to the other type. Then after being submitted, the form values need to be converted back so the original Model objects can be updated.
2) Pass the original InvoiceDetails collection to the View and have code there create render the CheckBox based on the value of the String property. I am still not sure how to handle the submission since I still need to map back the form values to the underlying database object.
Maybe there is a third way if not one of these two approaches?
To make the situation a bit more complicated (or maybe it doesn't), I am rendering the form to allow for the editing of multiple rows (i.e. collection).
Thanks for any insight anybody can provide.
You need a ViewModel, like #Justn Niessner suggests.
Your controller loads the complete model from the database, copies just the fields it needs into a ViewModel, and then hands the ViewModel off to the view for rendering.
I'd use Automapper to do the conversion from Model to ViewModel. It automates all the tedious thingA.x = thingY.x; code.
Here is an additional blog post going over in detail the use of ViewModels in the Nerd Dinner sample.
I believe what you are looking for is the ViewModel.
In cases where you are using a ViewModel, you design the ViewModel to match the exact data you need to show on your page.
You then use your Controller to populate and map your data from your Model in to your ViewModel and back again.
The Nerd Dinner ASP.NET MVC Example has some very good examples of using ViewModels.
I really hope someone can help on this because I'm learning cocoa and have hit a road block.
I am trying to model a simple poker tournament. For now, my entities are simply a Tournament (with a number) and a Player (with a Name). A Tournament has an array of Players.
I can bind two independent table views to display the tournaments and the players just fine. But I want the players table view to just show the players that belong to the selected tournament from the first table view.
Each has it's own array controller. I have tried a variety of different bindings for the second (players) table but to no avail. Has anyone accomplished this? If so maybe you could spell it out for me, as I there are few examples online.
Update
I can now ALMOST get where I need to, mostly through rial and error and hours of googling. I have bound the player AC's content to the tournament AC, with controller key 'selected objects' and Model Key Path 'players', which is the name of the array in my Tournament entity.
I have the bound the column in the players table view to this second Player AC, controller key arranged objects. But what to put in the Model Key Path? I know it is working because if I stick #count in there I get the correct number of players for the selected tournament. But 'name' and 'player.name' are no good. Is there any kind of 'item.name' or 'players.item.name' I can try?
Sooo close, thanks for the help so far:
I think this tutorial will help you. They also create a master/detail view.
In short: Bind the contentArray of your player's array controller to the tournament's array controller, set ControllerKey to selection and the remaining properties accordingly to your model.
I found the answer here:
Implementing parent->child drill down in Cocoa with Core Data bindings that span multiple entities.
The child controller needs to know about the managedObjectContext through its own binding.
The child controller must not be in Entity Mode, but rather operate as a NSMutableDictionary class.
And, finally, the child controller does not prepare its data. It retrieves it from the parent, through the Content Set binding. Use the controller key selection, and the model key path that connects to the children.
I'm surprised this is not a more commonly used practice, and hope the next person reading this doesn't spend so long finding the answer!
I can't find in the Docs where they explain all those fields and what they mean. Especially "Controller Key" is not clear to me.
[Copying my answer on another question…]
The controller key is the key for the (property of the controller object) you're binding to. The model key path is the key path by which the bound object can ask the model objects for more basic objects, such as strings or images, or for other model objects (i.e., drill down into the model).
An example: Let's say you have a Person objects in an array controller, and each Person has a name. You bind a table column to the array controller, controller key arrangedObjects (thereby getting the model objects), model key path name (thereby getting the value objects).
A more complex example: Suppose you have an array controller of Departments. Each Department contains Persons (employees in the department). You can bind your People array controller to the Departments controller, controller key arrangedObjects (getting the Department model objects), model key path #distinctUnionOfObjects.employees (getting the Person model objects), and then bind a table column to the People controller, controller key arrangedObjects, model key path name.
That table would be for people who work for your company; if you have a separate table of prospective employees, you can create Person objects for them, too, and they won't show up in the table of existing employees because they're not in a Department. When you hire them, you'll add them to one or more Departments; then, they'll show up in the People array controller automatically, because that array controller is observing the employees of all of the Departments.
The Controller Key pop-up menu is a way to help you discover what keys the controller (typically a NSArrayController, NSObjectController or a NSTreeController) presents.
The best example is the selection key of NSArrayControllers, which contains the set of selected objects. What is confusing is the NSObjectController presents a 'selection' key too, although the controller can control only a single object (therefore the selection = the object).
I agree that it is not clear at all. I personnally began to understand it when I bound my objects programmatically (i.e. using the bind:toObject:withKeyPath:options: method).
It has to do with key-value coding. You can bind a control in IB to a value in your controller. To connect that value, you have to specify the keypath to it. For example, if you have a textfield in IB and you want to bind it to say a field called 'name' in your controller, you would specify 'name' as the keypath. You then need to set up your name field in your controller to be accessible through key-value coding. This is done in 10.5 by using the #property and #synthesize specifiers.
Take a look at this topic: Cocoa Key Value Bindings: What are the explanations of the various options for Controller Key?
I posted an explanation of where to find definitions for all Controller Key's there.