In an effort to better understand organization using Backbone, I'm attempting to create a timeline much like Heroku's status page (https://status.heroku.com) and, of course, Facebook. In short, the timeline simply consists of days containing their respective events. I may be way off here, but this is the approach I've taken:
The router renders a days index view containing sub day views. Contained within each individual day are, you guessed it, the event views which occur(ed) on that day. Note: I see no need for the the day views to be be backed by a model, only the event views, as events are obviously stored in a DB.
Assuming this approach is acceptable (?), here's what's unclear to me: from where do I instantiate (and render) the event views? Should the day views fetch their respective event views? If not (and I'm assuming "not"), how do I ensure all day views have been rendered before fetching and distributing the events? Additionally, should there be an events index view that fetches and distributes the events?
Any relevant docs or blog posts on this topic would be greatly appreciated :)
Feels like you've already answered your own question - as you said, each individual day view contains the event views for that day.
So your day views would instantiate the event views and manage them. You may want to rethink your Model a bit - it may make more sense for the events data to be contain within each day - that would simplify things. In other words, when instantiating a day, you pass a DayModel to it. Within the DayModel is an array of events, and for each you instantiate an event view, passing that EventModel to it.
This is, of course, all speculative based on the simple description you gave above. Depending on how you want to visually render everything, you may find that the Events need to live outside of the Days.
Just keep in mind that Backbone.js is an extremely "open" framework - there's no one or right way to do something - so do what makes the most sense for your project's specific needs.
Related
I need real time charting (100-200ms updates) of a maximum of 20 series. After some research I settled on syncfusion because I can use the community license and at first sight it seems performant. The only drawback seems to be the sometimes lacky MVVM support.
To get a good realtime performance I found this blog post:
https://www.syncfusion.com/blogs/post/Deliver-high-performance-charts-with-Syncfusions-WPF-chart-control.aspx
I'm especially interested in the 'batch update' section because all 20 series will get updated at the same time, there's no need to rerender the chart 20 times.
An alternative seems to be this: http://help.syncfusion.com/wpf/sfchart/how-to/add-range-of-points-dynamically
I have yet to investigate the differences.
But how can I make this MVVM friendly.
Thanks for your advice!
This requirement can be achieved by accessing the SfChart control from its view(UserControl) which was initialized in the ViewModel class, to have access on SuspendNotification and ResumeNotification methods in SfChart.
Real time updates can be achieved in two ways.
By using auto-scrolling feature, to maintain a fixed amount point in view while real time update and also there is a provision to view old data through scrolling.
By removing the first record from the collection while adding new record at the end.
Demo Samples : Real_Update_Samples
Long story short, let's say one app has multiple pages with:
a form
a list
pagination
each page may require (now or in the future) custom actions to be implemented
My question is, witch is the preferred Backbone way of handling this and why (please argument) ?
Define, a pagination view, a pagination collection, a search model, search view, etc, and initialize each one as a child view in all the necessary pages. This means we will have to append child view elements into the 'master' element, and handle all the communication between these in all necessary pages.
Define a pagination view (with it's own pagination collection and search model) and extending it across all the necessary pages. This does mean that we will have to make use of template partials (for forms, pagination, etc) and bypasses the need of handling communication between child views while also removes the need of appending/removing child view elements.
Please add your way of handling these cases if not found above, remember to argument.
My personal opinion would be 2. And that is because it removes a lot of hustle with communication between child views and it makes everything much more easier to read just by extending classes, instead of having to 'manually' init child views. It also gives one the option to rewrite behavior per page when needed.
I think #2 is a poor choice.
It's a very good idea to keep templates as simple as possible. They are basically just the markup that's generated for some input object. In order to get that object to the template, in MV* frameworks you have Views, that can either pass a model to the template or send some formatted data to the template (I prefer this where possible).
Partials just create markup. You'll still have to handle events, updates to the DOM and rendering inside the view. If you only use one view it will have to handle a lot of things, something associated with poor maintainability and a more bug prone codebase.
You'll either have a lot of code in the views, or you'll end up with a lot of mixins or doing a lot of inheritance - and I have no idea which is worse.
Big things are a lot harder to test and to reason about. Avoid doing big things.
I think that another big problem with the template partials approach is the fact that you cannot rely on type information (something like interfaces), on the object that ends up in the template. It's probably easy to make it work when you have a partial or two that you just created, but, in time this information will get lost, leading to a bad development experience.
You'll need to make sure views unrelated to your changes are kept updated with the partial changes you just made for a feature.
Keep in mind that software is never done. Things always change.
Instead of thinking about relationships between models you'll have another complex challenge that you need to handle: the coupling of views through partials.
The alternative is a lot better. Composing specialized views is a good approach because each has it's own internal, smaller state and just it notifies listeners when some action takes place. Nobody cares about what's going on there until something happens and then you just get concrete data.
Going with #1 helps you deal with complexity in your application while allowing you to reuse them in other contexts.
Pretty cryptic question I admit.
I'm looking for references / best practice in updating views based on a GUI event.
Basically I'm seeing 2 different ways to do this:
every view-change is a reaction to a model-change
Gui event
viewhandler (custom or 2-way binding lib) that
updates Model based on view
the View has a listenTo defined on the MOdel that was updated, which gets invoked
do whatever DOM-changes we want
Do DOM-changes directly in the viewhandler
Gui event
viewhandler (custom or 2-way binding lib) that
updates Model based on view
do whatever DOM-changes we want
the View has a listenTo defined on the MOdel that was updated, which gets invoked
The fist approach seems the most clean to me: it can use validation rules on the model, before changing the DOM and the flow just feels better. However, I can't find any good references to back this up. What is generally considered best practice here?
I wouldn't know what is Overall Internet Agreement on that topic, but working on a fairly large Backbone application with complex views, the first approach is what has proven the most maintainable.
One way to see it is that as you know, Backbone's Views and Backbone's Routers are kinda sharing the workload of what would be an actual Controller in a standard MVC (say, Rails). What that means is that in a view, you'll typically have the logic to translate GUI events (click on X) to Model Change (do Y) and the logic to translate Model Changes (new state after Y) into DOM changes. That doesn't mean the logic needs to be in the same place, those are two separate things. Your model may be shared among multiple views and you need your View to react regardless of where the change is originating. You could also be waiting for the server to answer whatever, and so, the DOM update would be in a callback anyway.
A pattern I have been using a lot lately is to have a _renderUpdating() to update the DOM to let the user know that his action has been taking into account (add a spinner near to whatever triggered the change), but I let events do the actual re-rendering once the server has returned the new model.
There is nothing that prevents you from going with the 2nd approach in simple cases, but as your application grow, you'll be very happy to have more than just a single render() that erases everything (including subviews) and you'll be looking at having a clean break between view -> model (which is the role of a controller) and model -> view to allow for more flexibility.
I am working on a UI, using Backbone + Marionette.js, which displays the same Widget multiple times on a single page. I am struggling with whats the best way to contain events inside each widget. Lets say each widget displays a selected friend's Facebook information (interests, status feed, mutual friends). If the user changes the selected friend for that specific widget what would be the best way to update the models that are part of that widget?
Here is how I am thinking of solving this ...
Create Setting Model - when user selects a different friend inside a widget the Friend select view updates the Setting model.
Approach 1:
Controller listens to the setting model on "change" events and in turn updates all the relevant models. Each model will never know of the setting model.
Approach 2:
Pass setting model to each Model's options and each model listen's to the setting model and when it changes it does whatever it needs to (reload, etc).
These are the 2 approaches that come to my mind. I feel like I am liking the Approach 1 better, but I would appreciate any feedback from people that have used Backbone in a similar fashion.
Thanks,
Habeel
I would go for approach 2 using a singleton setting model as you suggested. That way the views or models listening to the settings are responsible for doing the updating. Approach 1 has two potential pitfalls. If you move the logic of what actually happens to the controller, it can become convoluted and complex. If the controller just reacts to change events on the settings model and propagate them to other models and views, then there seem to be little reason for it to exist.
Another approach could be to make use of Marionette's event aggregator feature. This would allow you to not even need a settings model. Instead, just have the changed model fire a global event that the other models are listening for and adjust accordingly.
In CakePHP I have a layout created and named default.ctp. In that layout I have a sidebar with some blocks and there're some statistics taken from the database.
My solution: I just created model called Sidebar.php and there're some functions, then I set up data in controller to display it in layout. Is this the best solution? As far I know, I will have to re-set every data in every controller, so need suggestions how to solve that.
Bear in mind that this is coming from a 10,000' level - I know nothing of your particular circumstances, but IMO it's not the best solution. I say that because you've created a model that represents a presentation component. If it were me, I'd probably look at using an element for display. Displaying dynamic components gets a little dodgy, but can be done without violating the MVC "covenant".
Your models should represent your domain entities (you've mentioned nothing about what your stats represent, so I won't offer any specific examples), not how they're presented.