I'm attempting to build a FedEx style scheduling board. This would look just like a week view on a calendar but instead of days it would have driver columns. The trips should be able to drag and drop between columns and appear at the correct height for the time.
I'm abstracting to ensure I have the correct logic before tackling the actual code.
So lets say I have a date on the index controller. Selecting a date will load the schedule for that date. The schedule contains drivers and each driver has trips.
What controller do I use to handle the trips? The content is different depending on the column but each column needs to be visible. Also I need to add events to these which presumably uses a view but ember will only ever load a view once. I'm sure I've just missed something fundamental but all the examples of ember apps I've found involve clicking a list item and loading in a view for that.
Am I thinking about my application with the correct mvc setup? Should I be approaching the problem differently?
Ember RC1 introduced a notion of an itemController when iterating through a list in handlebars:
{{each trip in tripList itemController='trips'}}
{{view YourApp.TripView}}
{{/each}}
That way each instance of your trip can have its own trip controller. We're doing something similar, and this actually saved us a lot of work.
Related
For this specific project, my team and I are thinking of leveraging the power of AngularJS directives and use them to build custom elements specific to our project, and use them like they were real HTML components.
For instance...
Say we have this table where each row is composed with a bunch of information that we get from a request, each row will be repeated with ng-repeat. Inside each row we will have multiple custom buttons with the same custom behavior. This button will also be used across different modules/pages on the website and not only on this specific table.
Our first thought was to use 2 directives, one for the table row and one for the button. The idea is that these are custom components/elements with custom attributes to define the custom behavior of the element. This would allow us to have a really nice modular application where each component is developed and unit-tested individually. Our HTML would also be easy to ready and understand.
Does this sound good?
Now, what about performance issues? Could we encounter big issues with this approach if, say we have a table with 100 of those rows and 5 of those buttons per row. Could this be big a problem if those rows/buttons had a couple of bindings to update information each X seconds?
The father of Angular Misko Hevery has this to say about performance and data-binding:
How does data binding work in AngularJS?
But in short like he says as long as you dont have more than 2000 data-bound items per page performance wont be an issue...
Here is an issue I've confronted in multiple user-facing applications: a program contains components for graphical rendering of data, (call them views) and other components for managing those data (call them models). Some of those data are in the form human friendly text, often key value pairs such as
System Load: 20%
Running Time: 20mins 30sec
But which software component should be responsible for constructing the text strings? You could argue
The model: should choose the text while leaving the view to display it. This way the views don't have to know exactly which data are provided, and (probably) lets the model expose only a small API. Also it means that the text stays consistent across multiple views (or UI toolkits). This ways views don't have to worry about i18n.
The view: should do it because this is a UI issue, not part of the business logic. After all, the choice of text is not always cleanly separable from rendering. This way models don't have to worry about i18n.
How should I settle, or think about this division of labour? Any ideas?
Note 1: I don't think this issue is restricted to MVC designs, although that's where I get my terminology.
Note 2: While researching this question I stumbled across Presenters, and ViewModels. Are they supposed to do this kind of work, and when is such a proper/complicated solution worthwhile, and when is it OK to just do it in the Model or View.
Taking this from an MVC perspective, if I have data to display in my view I will (almost) always create a viewmodel which the view inherits from, with the viewmodel properties of the correct type for the data. e.g. in your example above I would have SystemLoad as decimal, and running time as a number of seconds. I believe it is then the responsibility of the view to determine how that data is displayed (how the user VIEWS it).
Using the ViewModel approach makes it very easy to define multiple views to represent the same data. A controller need only know to supply and receive a specified class - the ViewModel - which can then be passed to whichever the most appropriate view is to be rendered. This rendering could be rich HTML for full browsers, stripped down for mobiles, or even a JSON response for an API, either way the controller need not change.
WRT to the original question, this is just an example of justification for leaving the formatting to the View. Whether you use viewmodels or not, this logic does not belong in the controller
As a general rule I would suggest leaving to models anything that is abstract and to the view, all the specific. For example, a model would have system_load: 0.20 and running_time: 1860 but y our view would turn these two values into actual useful, viewable information.
I think I'm finally starting to get MVC 3, but if someone can validate this approach I'd feel better about it.
I have a website, let's say, and I have models for NormalPage and EventPage. EventPage has an EventDate, but that's the only difference, and let's just say that EventPage inherits from NormalPage if that makes life easier.
Two views handle these two (slightly) different models, one just showing the page, and the other displaying the date and showing a registration form. They have different designs, so different views are in order.
All the tutorials will say "yup, now write two Controllers: Events and Pages". That seems silly - both are just passing the model to a (appropriate) view. I can use a single "Page" controller and choose the appropriate view using reflection, right? typeof(Model), once I've pulled the data from the database, can tell me whether or not I should pull the Event view or the Page view.
Is that dumb, or asking for trouble, or misusing the framework? Thanks.
What do you intend to do with reflection? You don't need to do anything like that to return views dynamically. From any controller action, you can return View("EventView", eventModel) or View("NormalView", normalModel) and it will return that view.
On a different note, I'm not sure what tutorials suggested that it's typical to have one view per controller but it's not. It's typical to have several views and actions in one controller.
I've been working this issue for a while now and I am open to any best practices/advice.
The Example
So I created a sample Core Data application. The application is basically a mimic of the AddressBook application. I have the following Entities: Group, Contact, Address, Phone, Email, Webpage, Dates.
As you probably are guessing, a Group can have multiple Contacts, and a Contact can be in multiple groups. Contacts can also have multiple Addresses, Phones, Emails, Webpages, and Dates.
I basically imported some 600 contacts into this application from AddressBook. The user-interface is relatively simple...a Group/category list on the left and an NSCollectionView or NSTableView on the right that shows the list of contacts depending on the selected Group.(collection view or table view...as I added the ability to display either view, both of which are bound to an NSArrayController)
The Group elements I am pulling in through code as opposed to Interface Builder, becasue I wanted to playaround with a Thing's - like sidebar, and it was far easier to do it this way.
The Problem
One of the categories contains all of the contacts while the other category contains merely 2 contacts. When i select the category that has all the contacts it takes anywhere from 8-10 seconds for the information to populate the collection or tableview. However doing the same thing in AddressBook itself is very speedy, almost instant. I am using the SQLLite store type, and have tried using a number of different approaches including trying to diagnose the problem via Instruments, but nothing has worked.
I've tried setting a predicate to the defaultFetchPredicate of the Contact's array controller as opposed to setting a filter predicate, but that didn't work.
I tried preFetching and faulting but i'm not sure if I'm doing it right, and not really sure how to accomplish it if Interface Builder handles the Contact's NSArrayController.
The Other Example
I've also tried downloading a sample Core Data app...while it has a simpler relationship model than what I did(basically a Molecule has Atom objects and an Atom object has Element objects), I inserted 65,000 records and it performed like a charm.
The Question
I've basically hit a wall and I'm wondering if anyone else knows why this is happening and the best ways to fix/overcome/avoid this type of issue?
Thanks!
It turns out that it was actually the NSCollectionView that was slowing things down. I guess the creation and manipulation of views x number of collection view views adds a significant amount of overhead. IKImageBrowserView could have been used but it wasn't what I was looking for.
I ended up changing the application layout to solve this issue.
Thanks all!
I'm developing an app which has a large amount of related form data to be handled. I'm using a MVC structure and all of the related data is represented in my models, along with the handling of data validation from form submissions. I'm looking for some advice on a good way to approach laying out my controllers - basically I will have a huge form which will be broken down into manageable categories (similar to a credit card app) where the user progresses through each stage/category filling out the answers. All of these form categories are related to the main relation/object, but not to each other.
Does it make more sense to have each subform/category as a method in the main controller class (which will make that one controller fairly massive), or would it be better to break each category into a subclass of the main controller? It may be just for neatness that the second approach is better, but I'm struggling to see much of a difference between either creating a new method for each category (which communicates with the model and outputs errors/success) or creating a new controller to handle the same functionality.
Thanks in advance for any guidance!
My preference would be to create triplet Form-Controller-Model for every form displayed to the user. Whenever user clicks on 'Next' button on a form its controller should talk to the back end manager which takes care of dispatching submit request to the next form in chain. Vice verse if 'Back' button is clicked. Last form has a 'Finish' button which will go to the manager and pass the last bits of information.
This will avoid inheritance, make your code more robust and testing of forms possible in isolation.
My preference would be to keep it all in one controller. It keeps all the relevant processes for filling out the application/form in one place, although I'm not sure how "massive" you're talking about. If you do decide to split it out, I would not subclass off of the main controller, but just make a handful of independent controllers, perhaps related by name for ease of use down the road.