An ambitious application?


#1

Hi all. I’m currently evaluating Ember as a possible candidate to move our existing application over to.

The main reasons for change are to reduce boilerplate code, encourage consistent development of features by different developers and take advantage of data binding. A speed boost would be nice as well :wink:

I’ve been reading through the docs, looking at other examples and browsing this forum and I feel I am slowly starting to ‘get it’, but also wanted to reach out to get a sense of best practices for an application such as ours.

Context

To give something slightly more tangible to discuss, here is a basic wireframe of one module in our application.

Our application follows this basic setup throughout, but with the views changing for each module. A module might be a Task Board (ala Trello), a Project Spreadsheet (hierarchical with Gannt), a Settings page or a customisable Dashboard etc. See this video for more of an overview of the existing application if you’d like: http://vimeo.com/75415900

Throughout the application, selecting an item in any view causes a ‘detail’ panel to slide-in providing more information and actions around that item. There can be different aspects available for a single item which we group into tabs. For example we have a Notes tab for threaded conversations around the selected item. A parent item would also display all the conversations from its children.

In the application we also use events to inform other parts of the application to update (when a property on an item changes for instance). Events may come from outside the application.

With the above in mind, I am looking for insights from experienced Ember folks on how such an app might be modelled in Ember following best practices.

Some specific questions:

  1. Is this app suitable for Ember? I feel like it could benefit a lot, but most of the examples I have found have not approached this level of complexity.

  2. What routing setup would work best within Ember for such an app? Currently our URLs look a bit like: http://appname.com/#view=scheduler&mode=projects&entityId=31fsf89as7&detailEntityId=safhh383 Note that it is a flaw in the current application that the Tab for the slide-in is not stored in the URL, so when sharing links the selected tab is chosen based on the last visited tab of the current user. I almost feel like the URL should have ‘blocks’ separated by a marker such as “|” for each distinct part (such as the slide-in). E.g. http://appname.com#/view/scheduler/projects|/detail/entityId/notes

  3. How much ‘state’ should be stored in the URL vs on Controllers? I’m guessing things like the spreadsheet applied filters would be on the Controller (though we do persist them to the backend datastore as well).

  4. Should the application modules be comprised almost entirely of Components as each module can be considered a kind of preconfigured dashboard?

  5. For the specific module above, how would the left navigation tree and main project spreadsheet share a common data backend even if they are different Controllers, so that updates could be reflected in both without duplicating data, but provide different views and actions?

Looking forward to any discussion and thanks in advance for your comments.