Thanks, Eric. I have tried the ui-router and that indeed seems like a better approach. You said I should model each data type as a custom element to allow in-place editing. In my case I am getting the data through a Web API, hence as a JSON object that is automatically converted to a jscript object. Considering this, do I still need a separate model? Doesn't that jscript object already serve as the model?
On Thursday, November 20, 2014 10:41:16 AM UTC-8, Eric Eslinger wrote: > > Opinions ahead. I'm no expert. > > You should look at ui-router for sure. It's like fifteen times more useful > than ngRouter. I use it to define nested views, which can be swapped out > dynamically. So I define a header, body, and footer on the / route, and > then can say "in these subroutes, use the three-column template for body, > and in those subroutes, use the wide-right template", and then on the > sub-subroutes, populate the left/middle/right views of the included > three-column template. Our body templates (and the whole thing really) are > built on reasonably-responsive defaults from twitter bootstrap, so the > three-column view turns into a very long one-column view on a phone, for > example (with a nav menu for quick movement within the column)/ > > From there, you should also work with custom directives to display each > data type, rather than just using ngInclude (IMO at least). Modeling each > data type as a custom element means you can encapsulate the view and edit > modes within the element for in-place editing. > > e > > > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
