Is it good practice to have multiple statemanagers for the purpose of splitting up multiple outlets that need to maintain separate functionality?
Examples:
iPad style popover windows (http://metalabdesign.com/images/screenshots/flow-inside.png) - this is a separate controller and view then the current state. It makes sense to me to have a "popover statemanager" - that way the router still stays in its current state when the popover is opened - all the other buttons and actions on the page still work...
Modal windows, dynamic sidebars, etc...
My thinking is to have a router the controls the main interaction and it simply fires off commands to statemanagers that break up certain "sections" of the current "screen" to isolated parts.
You should have only one router. Then architect your whole application as a series of states interacting between each other through the router. This way your whole application is much more manageable and easier to test.
You might want to look at This presentation for further insight on the subject.
Related
I know this question might seem a little duplicate but the other version of this question is old and some of the content (such as Views) aren't even a part of ember anymore.
I'm about 4 weeks into my internship as a front-end developer working with EmberJS. I still don't understand when it's better to use the route over the controller or vice-versa. It seems to me that every action in the route can also be used in the controller.
The one recent thing I heard was that ember routes should be stateless where as controllers should be stateful.
What is the current state of controllers and routes. When should one be used over the other?
Consider the following example to understand the state of a controller (or route, or anything), in simple terms and in current context -- lets say you have a page (like a form) with three tabs; each tab can be considered as a state - it would call different components based on the state (or the tab you are in). Now if you would happen to go back for some reason, and hit the form link again, you would see that the state would remain the same. (if you were on tab 2 when you hit back, on returning to the form, you would still be on tab 2).
So to maintain these states, controllers are the way to go, since they are singletons. Route would have lost that information, and started fresh. So basically your variables/objects in a controller would define the 'state'.
Route-actions can be as easily used as controller actions- see https://github.com/DockYard/ember-route-action-helper. So if your template for this route is just using model as the object directly, and you don't need to maintain the 'state', you can pretty much do without your controller.
But if your template was using variables which needed manipulation, you would need controller.
Hope this helps!
I'm wondering if their is a tutorial on how to convert an admin UI into Ember components? What are the best practices? For example, the following UI framework: http://egemem.com/theme/kode/v1.1/blank.html
Has a main navigation, two sidebar menus, a content body and a footer. What would the best approach be to converting this into components? My initial thoughts, with very little Ember experience and based on the scattering of documents I've been able to find, I get the sense that creating unique components for everything would be the best approach. By everything I mean, everything that is unique. For example, if we take the navigation bar, there would be a parent component for the navigation as a whole and then child components for the sidebar collapse/expand buttons, the search, the drop down menus, notification indicator, etc. There would also be additional parent components for the right hand sidebar, left hand sidebar, and footer.
Looking at one of the sidebars, for example the left one, could that be one component or would child components be required here as well?
The right hand sidebar is more complex with tabs. In this example, would it make sense to break this sidebar into child components for the 3 different tabs? Would you want to go as far as a unique component for different elements of the tabs themselves. For example, each notification type would be a component?
Thank you in advance for your assistance send I look forward to understanding how best to handle this type of scenario.
Cheers,
Dan
Yes, your idea makes sense. It is a good practice to create components (or handlebars) for everything that repeats several times. I would not create different components for different tabs if they are not re-used.
Do not forget to not re-invent wheel. There are a lot of available components, take a look at Ember Observer or other similar resources.
Components are great but some the things you mentioned, like sidebars, might make more sense as nested routes, depending on what's in the sidebars.
Rock 'n Roll with Ember is a fantastic book that takes you all the way through the process of building an Ember application. It's the book I always recommend to people just getting started with the framework. http://balinterdi.com/rock-and-roll-with-emberjs/
I have an application scheme implemented in Ember that basically follows this layout:
The concept is that the user can interact with features on the Map View (which is always present) and basic navigation occurs between various views in the Parent View and an arbitrary stack of Sub Views. The user can create new features on the map, edit existing ones etc.
The URL for a particular feature could be /features/123/edit
Since input into my interaction panels is very much dependent on interaction with the Map View (drawing a polygon, placing a marker etc.) my controllers for these views are setup to "need" the Map Controller. When a particular panel view is present interaction with the map should affect the panels in various ways.
My question is - how does one scale such tight controller coupling? I essentially need to switch between different Map modes based on which panel is currently active. I also, I believe, need to observe events on the map and act upon such events depending on the current active panel.
I setup a proof of concept where a certain Sub View Controller observes certain properties of the Map Controller (with for example .observes("controllers.map.activecoords") however, such an observer will continue to trigger even after the user has navigated away from the particular Sub view (i.e. as soon as the controller has been initialised). Must I setup and tear down such observers manually (i.e. using addObserver) when entering and leaving the route? Is this the right pattern? I've gotten the impression that requires that I manually remove all such observers during transitions to avoid unexpected behaviour and memory leaks.
Perhaps I'm going about this completely the wrong way? Are there any others patterns that fits my use case with an always present map with different states and intercommunication with interaction panels?
Perhaps the architecture of your application shouldn't be connecting controllers, but rather ask yourself "What is the model here, really?"
In each case, I think the model is your map, or at least its "contents". The features are really decorating the interaction with your central model, which is the map, underlying it all.
So really you have a single model here. You effectively have a map resource, and many feature routes on that resource, viewed from the URL/API.
The question is now not so much "how to manage a dependency hierarchy between controllers?" as "how do I manage a view and a subview on the same model?" which is answered quite simply in the standard ember nested route. Your outer view is always present and it has an outlet which is where your feature goes. How it's rendered is the inverse of how the standard nested route is rendered, but nevertheless it's the same pattern.
So, the TL;DR answer is... go through your model and the routes... use them to talk about your common data: the model is, afterall, your data, and the controllers and views are simply augmenting and enabling the user experience, presentation and interaction of them.
Most of these sorts of architectural problems can be resolved by moving the data up and down the hierarchy (template view / component / controller / route / model) until you find a place which is low enough to still be accessible to objects that need access to it, yet high enough that it makes sense by not being tightly bound with too many things, but still is in the right spot and "feels right".
If it's too high, you'll tend to be doing the wrong kind of work with your objects (ie controllers should not be mucking with view mechanics, models shouldn't really have presentation stuff in them, etc.
If it's too low, you'll tend to be doing too much work with the framework and you'll tend to be repeating yourself a lot... ie controllers will be doing a lot of work to get the data they need, for example.
I'm just starting with Backbone.js. I'm building a Single Page Application and trying to figure out how I can handle this situation.
Depending on the view I'm rendering, I need to output multiple templates, meaning I have a wrapper that I use for the main template, and other 2 templates that go on other parts of the HTML.
I started by manually outputing the templates, but that got me thinking how correct that approach was, as it would require me to manually delete them whenever I navigate to other view.
The question is, How can I effeciently render multiple templates in a single view (that are appended in different places) and still have control over the deletion on the entire view and undelegating its events?
I'd check out Addy Osmani's walkthrough for developing with backbone.js.
http://addyosmani.github.io/backbone-fundamentals/
It walks through the example todo app, and then one more complicated one. What I think you want specifically is to use a framework such as Marionette.js to orchestrate and automate some of the event delegation and removal when you play with your views. If this is the case, skip to http://addyosmani.github.io/backbone-fundamentals/#marionettejs-backbone.marionette and read on about how marionette will help organizing views into regions and layouts as #NathanInMac said.
You need a layout with a couple of regions.
Then put your sub-views in these regions.
Are controllers in ember.js meant to be tied to main view areas/scenes a la iOS, or more tied to a set of data?
Is it common/wise to have several main views tied to the same controller in ember?
In iOS main portions or sections of the screen are tied to a single controller. If you want to present another main interface, say a modal window to create a new element, you (typically) have an entirely separate controller to manage that view and its data/logic.
In something like Zend Framework, you have controllers that might perform some common spinup steps of ensuring authentication, but largely the actions play the role that controllers do in iOS, handling the logic and providing the data for 1 main section or view (being the web, this usually ends up being the whole page).
What is that typical role or advised pattern for using controllers in ember?
You have a couple different questions here so I'll address them one at a time.
First, you asked if controllers should be data oriented or view oriented. In my experience both behaviors are allowable. Controllers are an excellent way to manage data sets for your application, including things like filtering and searching. Evin Grano wrote a good post about this from the SproutCore perspective and most of the concepts should apply to Ember as well: http://www.itsgotwhatplantscrave.com/2009/07/30/root-controller-paradigm/. Controllers are also well suited for controlling the application state and behavior. For example, you might put a method in a controller that is bound to as a button action elsewhere in your app. However, you should also examine Ember States to see if these might be better suited to your scenario.
Secondly, you asked about tying multiple views to the same controller. Personally, I see no concerns with this as long as the controller maintains a distinct purpose. If the views are logically related and share in the same state or data then a single controller makes sense. If you find the controller growing to cover too many different areas, you should consider splitting it into multiple controllers.
From my limited experience in Ember.js, I have regulate to the following:
The view handles user actions related to changes in the presentation layer, limited to its own instance.
A navigation controller/statemanager handles complex manipulation of what is presented (add multiple views, remove some other, etc.).
The controller responds to user actions related to the data layer.