There are two things to consider. If you are encapsulating some view-edit-save-undo kinds of features, it can be really helpful to define a directive instead of defining a bunch of extra behaviors in javascript on the page controller that handle editing and saving. To that end, you could extend the json you get from your service with some save / new / revert type functionality (which ng-resource does pretty well if you have a conventional API), on the javascript object that represents the data. On the other hand, you could define a directive that encapsulates a couple of different ways of representing the same data (in view or edit mode, in different graph forms) that are reasonably pluggable into the overall interface. That will DRY out your html view code and make it easier to improve in the future.
If you find yourself using an array of state variables alongside your view variables to keep track of dirty or expanded or whatever, that's a sign. On the other hand if it's simple and you just need to do super-basic get/put commands on $http, it can all fit into the view directly. If you find you're using ng-controller a lot (or at all), that's a sign too. It's really a common pattern to define some directive for displaying your data object, and then do a <my-object-directive ng-repeat="item in list" my-object="item"> sort of thing. e On Sat Nov 22 2014 at 11:16:08 PM Rob <[email protected]> wrote: > 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. > -- 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.
