Pedr did you ever come up with a good solution for this? I have a very
similar background as yours and I struggle with the same problem. Something
we have done is wrapped all of the galleries in their own object where it's
basically {transitive: ..., data: ...}. We chose this because we want to
easily update the data from the backend without loosing all the transitive
properties. This entire workflow is ignored heavily in a lot of the
suggested practices which is frustrating from a model layer. It's ignored
because usually $scope has those transitive needs but sometimes you need to
share that across the app like your example. So we have the annoying
overhead of half the data is in one root object and half in the other. We
don't really like it so we are trying to limit it as much as possible.
I have considering updating data via angular.extend instead of angular.copy
and have the transitive properties live in the main object but it's not a
perfect solution either.
On Saturday, May 18, 2013 at 9:14:14 AM UTC-5, Pedr Browne wrote:
>
> Hello all,
>
> I've recently started using Angular and I've been really impressed by it.
> However I've found the Model aspect problematic. The decision to not to be
> over-prescriptive on Models is a wise one, however I'm struggling to see
> how to deal with more complex Model relationships within Angular. Most of
> the examples I've seen keep model state on the controllers' $scope object.
> In many cases - when the state is directly related to the view such as in a
> form, this kind of View Model makes complete sense. However, with a larger
> application where model state is not so explicitly related to the view,
> this approach seems like a bad one. If a model is used throughout the
> application, storing its state in a single controller does
> not necessarily allow it to be shared with other controllers (obviously
> dependent on scope inheritance / DOM hierarchy). I've found that a side
> effect of using this approach is that model state often needs to be tracked
> on root Controllers so that other controllers can share via their scope
> objects.
>
> I spent a long time working with Flex and a framework called Robotlegs
> which is very similar to Angular in many respects. This workflow made heavy
> use of Models wrapping dumb VOs/DTOs, offering mutators and managing state.
> These data objects at the core of the models were manipulated as needed,
> with the model storing state that was not encoded in the data (for example
> selection). This meant the data was never polluted with state that was only
> relavent to the application, and allowed the rest of the application to
> share the model, reacting to its state changes through events or bindings.
>
> Now I am in no way suggesting this is the 'correct' way to do things. It
> worked great for me and it is how my brain is currently wired to think
> about the model layer. Where I'm stumbling is in seeing the equivalent in
> Angular. Most Angular applications feature simple models; usually a
> collection(Eg. ToDos) which are acquired from a Resource. In these
> situations, using a Singleton service to wrap the model makes sense, and
> offers a nice place to add mutators and maintain model state. Where things
> become more complex is in situations where model relationships go deeper;
> for example if the data was a collection of Themes, each of which has a
> collection of Galleries, each of which has a collection of Photographs. At
> this point, a Sington service no longer makes sense and it would seem to me
> a necessity to distribute the model data amongst a graph of Model classes
> which can offer mutators and track state, but this is not something that
> seems to be encouraged or explicitly supported.
>
> So my question is how should situations with more complex model graphs be
> handled? For example in my Themes>Galleries>Images example above , if we
> pretend that we need to track the selected image for each gallery over the
> course of an apps lifecycle, where should this state be stored?
>
> Hope that makes some kind of sense. I posted a related question on Stack
> Overflow yesterday:
> http://stackoverflow.com/questions/16607874/where-should-model-state-be-stored-in-angular-js/16623282?noredirect=1#16623282
>
> Sorry about the verbosity and thanks for reading this far.
>
--
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.
