I am working on an iPhone app, and in a particular view I need to load two different entities: One that will populate a UITableView, and another that will populate a UITextView.
Is it possible to fetch both properties using a single NSFetchedResultsController?
Or do I need to use two different NSFetchedResultsControllers?
Any ideas on how to best approach this problem?
Each fetch request has only one entity and each fetched results controller has only one fetch. Therefore, you need separate controllers for each entity.
If you think about it, how would you make a predicate to fetch two logically separate entities?
You probably don't need two fetches at all. In most cases, you can fetch the entities that populate the table and then use a relationship for the entity of the selected row to populate something like a text view.
Best solution would be to refactor your Model and see if your 2 entities have something in common. You can make an abstract entity for the intersecting stuff, then inherit your 2 entities out of that. Perform the fetch on the abstract entity, and your fetch results controller should return mixed results.
As TechZen stated, the answer is no.
However, you can monitor the saves of the NSManagedObjectContext yourself and react to those saves. If you really do need to watch more than one entity (something that is far more common on the iPad than the iPhone) then add a NSNotification observer on the NSManagedObjectContextDidSaveNotification and look at the -userInfo of the NSNotification that comes back. You can then run predicates on against the results to determine if you need to update your display. That is what the NSFetchedResultsController is doing under the covers.
The quick answer is NO. But I found a creative answer.
In your tableViewController, make a search bar with how many scopes you have.
When different scope is selected, you can fetch different entities!
This works because I made an app like this!
Users would have easier time separating the two different data too!
Related
The small web application I am working on is becoming bigger and bigger. I've noticed that when posting forms or just calling other functions I've passed parameters that consist of IDs or a whole instance of a Model class.
In a performance stand point, is it better for me to pass the whole Model object (filled with values) or should I pass the ID, then retrieve from the database?
Thanks!
For Performance benefits, you can do lot of things, common things are
1) Fetch as many as records which are needed, e.g. customized paging, in LINQ use (skip and take methods)
2) Use Data caching in controllers and Cache dependencies for Lists which are bound with View
3) Use Compiled query to fetch records. (see here)
Apply all these and see the mark-able page load speed.
EDIt: For IDs recommendations, In this question, Both will be same performance impact if you pass only ID and fetch rest of the model from database OR pass filled model.
Do not solve problems which do not exist yet. Use a tool to measure the performance problem and then try to solve.
It is always best to consider these from the use case.
For example, if I want to get an item by ID, then I pass the ID, not the whole object with the ID filled out.
I use WCF services to host my BLL and interface to my DAL, so passing data around is a costly exercise, so I do it sparingly.
If I need to update an object, I pass the object, if I just want to perform an action on an object, such as delete or get, I use the ID.
Si
If making things work is only requirement, we can put all controlling login and DB handling logic even in the views & it will work. However this is not a right approach for reusable design.
Before I ask my real design question, below is my current understanding about separation of responsibilities in terms of model.
All Database related code, even db related logic, should go in models.
For a table, say 'my_tab', propel generate 4 classes, out of which only 2 classes 'MyTab.php' and 'MyTabPeer.php' should be edited.
MyTabPeer.php must only have data fetching.
Any logic, if required to fetch data, should go in 'MyTab.php'
This is simple and I hope it is correct, if not, please correct me.
Now, I have a special condition. I've 4 tables, say a, b, c, d. For that, propel generated 8 editable classes (excluding base*.php)
A.php APeer.php B.php BPeer.php
C.php CPeer.php D.php DPeer.php
One page of my application, shows Mailbox (say). Mailbox is not a table in database but it gets its data from complex join query between above 4 tables along with lot of calculation/conditions.
I generated that query, fetch data from it and displayed it. Mailbox is running as expected. However I did it in my controller (action class), which I know is not a right place for that.
My question is, where should I put that code? Possible options:
Controller, I think, is not a right place for DB logic/fetch.
I've 8 model classed however data do not belong to any one of them but as combination of them all.
A separate helper/lib, but I know I'll never reuse that code as its unique page of the site.
Anywhere else?
Please suggest if I'm wrong but I guess I should put it in models as it is fetching data. Since A is primary table, I probably should put code in A.php and APeer.php. If that is correct place, next question is, What should go in A.php & what should go in APeer.php? I've following operations to do:
Some logic to decide what columns, should I select.
As like mailbox, I can show received/sent message. Controller will tell what to show but there are some db logic to set conditions.
Then really fetch data from complex Join query.
Returned data will have all rows but I might need to merge few rows conditionally.
As per my understanding, Point 3 should go in APeer.php and rest in A.php. Is my understanding correct?
You should create separate model class i.e. Mailbox.
Method of this model should do the complex select and return data to your action in controller. This solution will not break MVC approach.
I'm an old CFML developer, new to CF on Wheels and MVC programming in general. I'm picking it up pretty quickly, but one thing that isn't evident to me is how one can offer a form to optionally update multiple db table records (models). I'd specifically like to set up a tabbed form for User info and User Profile info, where the former is required and the latter is not. This data is stored in two different one-to-one tables. What's the setup I need in order to call two "new" or "edit" views, run 2 "create" or "update" procedures, affecting two different tables. Or am I thinking about this all wrong.
Update: Adding some more info on what I'm trying to do. To keep it simple, I'll stick to 2 tabs and 2 tables, though I'm really looking at at least 3 in this instance.
So I've got a Users table and a UserProfiles table, and I've got models named User.cfc and UserProfile.cfc that are related 1-to-1, with UserProfile dependent on User. Pretty standard stuff. For each I've got controllers: Users.cfc and UserProfiles.cfc, each of those containing actions. add, edit, create, update, doing the obvious stuff (add and edit display forms). I have partials that display the add/edit form fields for each, so that's already prepared. Now, I want to create what is effectively a single add/edit form that can update both tables at the same time. The tabs don't really matter; effectively it could all be on one page.
So conceptually I'm doing something like:
#startFormTag(action=???)#
#includePartial("form_user_add-edit")#
#includePartial("form_userprofile_add-edit")#
<button type="submit" class="btn">#operation#</button>
#endFormTag()#
Do I need to create a separate controller action that basically combines the create and update actions for two different controllers?
Thanks in advance from a pleased and eager CFWheels newbie...
Brian
If all of the data is related through hasMany or hasOne associations, I'd recommend looking at nested properties.
http://cfwheels.org/docs/1-1/chapter/nested-properties
If you're a newbie though, you may want to refrain from this until you've got something simpler worked out.
I guess you are talking about two models representing these two tables, possibly associated using hasOne. Models allow you to validate data, this makes controller much simpler. This way you could create two forms under two tabs, and keep record's primary key as hidden field. Controller could run the validation and re-display the forms (partials may help)... Hold on, I am just going through the reference.
I realize this answer is pretty generic, as well as your question. I suggest you to go ahead and try something, see how it works.
After that update your question with code samples and ask if you have some specific problems. For example, validation and displaying errors in CFWheels may be a bit tricky.
I have a working system that lets me build a database containing instances of various entities , all linked together nicely.
Before I knew I would care, I came across a tutorial on using Core Data and bindings, and it went through a complete case where you get a table showing all the entities of some type with a column for each property. It showed both the UI side and the Data model side - not that I need the data model part at this point. Now, darned if I can find it. This is one of those things that is supposed to be easy, and requires virtually no code, but getting exactly the right connections in UIBuilder is not going to happen if I can't find instructions.
Also, I thought I came across an example of something like a query editor where the user could select which properties to sort on, which to match on, etc. Did I imagine that?
Anyone out there know where I can find such?
Sure, you can do this without code:
Add an array controller to your nib.
Bind or connect an outlet for its managed object context
Set the array controller to Entity mode, fill in the entity name, and select Prepares Content.
Bind your table view columns to array controller's arranged objects, and fill in the key name for the model key.
Regarding the query editor, open up the model, and on the Editor menu click Add Fetch Request.
I found at least a partial answer to the query editor question, in this apple tutorial. Not sure how far it will get me, as I prefer to write code where possible, since then I can leave a trail of comments.
I have a web application built on an MVC design.
I have a database which contains a large number of objects (forum threads) which I can't load into memory at once. I now want to display (part of) this collection with different filters in effect (kinda like what stackoverflow does with questions sorted by date, votes, tags etc).
Where do I implement the filtering logic? It seems to me that this must go into the model part of the application, as only models interact with the database (in my implementation). If I make the filtering a part of the view, then the view must access the database directly to get the list of filtered objects, right? I'd like to avoid this, because it exposes the database layout to the view. But at the same time, displaying different views of the same data should be implemented in the view part of the application, as they are just that -- different views of the same data.
So how do I resolve this? Do I create an additional model, say, FilteredThreadsList, and have it remember the filter to use, and then use a FilteredView to display the list of threads that FilteredThreadsList spits out?
Or do I have to build a ThreadQueryier that allows views to query the database for certain thread objects, so I can have the filtering logic in a view without exposing the database backend?
You should never query data from the view. I don't know what framework you are using in particular but as for Ruby on Rails (should be the same for other frameworks) we always pull the necessary data from the controller and store all that information into a variable. The variable will be accessed by the view which can help you avoid querying your database directly from the view.If the code to query the database gets too lengthy in the controller, insert that code into the model instead so it's more maintainable for your project in the future. Additionally, you can call this model method from multiple places in your application if needed. Good luck!
From an architectural point of view, the model should be having the code for filtering. This is so, because in many applications the code for filtering is not trivial and has a good amount of domain logic in it. (Think of filtering top gainers from a list of stocks). From your example as well, it looks the same since you might want to filter by vote or by date or by tags and then by answered or unanswered etc.
In some very simple applications that deal with search/list of entities and allows Create/Read/Update/Delete of an entity, the pagination, sorting and filtering logic is usually very generic and can be implemented in a controller base class that is inherited by all entity-specific controller classes.
The bottom line is this: if your filtering logic is generic put it in the controller else put it in the model.
Model, that's only bunch of entities.
View provides a visual representation of the data from model - use as much of views as you want. If your application is web based, you can fetch data into browser just once (AJAX) using and re-use them for different UI components rendered in the browser.
As for what entities and what view to use for their representation, I think it's work of Controller. If you need some support for it on "model layer", add it but avoid tight coupling.