Thanks very much Jim, that's really useful stuff. On Saturday, March 9, 2013 2:30:59 PM UTC, Jim foo.bar wrote: > > also see this for a discussion about why the need for design patterns > almost disappears in Clojure: > > http://stackoverflow.com/questions/8902113/clojure-model-view-controller-mvc-design > > Jim > > On 09/03/13 14:24, Jim - FooBar(); wrote: > > You need to store your model in a ref-type (atom,agent,or ref), and attach > a watcher on it (a fn which is responsible for updating the view). Now, > 'mutating' your model will trigger a View update...piece of cake :) > > example: > > (def board-history > "Log of the state of a game." > (atom [])) > > (defn log-board > "The logging function for the board ref. Will conj every new board-state > into a vector." > [dest k r old n] > (when-not (= n old) > (swap! dest conj n))) > > (def current-chessItems > "This is list that keeps track of moving chess pieces. Is governed by an > atom and it changes after every move. > All changes are being logged to 'board-history'. Starts off as nil but we > can always get the initial board arrangement from core." > (-> (atom nil) > (add-watch :log (partial core/log-board core/board-history))))) > > HTH, > > Jim > > ps: my example does not involve GUI, but you get the idea...it it trivial > to change the code so that it 'repaints' the canvas with the new board > instead of conjing it.... > > > On 09/03/13 14:11, edw...@kenworthy.info <javascript:> wrote: > > So I understand that Clojure's data structures are immutable but I am not > clear how that works with MVC. > > So I have a view that displays a model. Other processes change that model > and the View presents those changes. > > However it's not clear to me how that would work with an immutable model. > > Obviously I can't pass the model into the View, have the view store a > reference to it and each time it's called on to render the model, do so. > The model is immutable. > > So I could have a global variable which points to the model, and whenever > I 'change' the model I re-point it to the updated version. Obviously the > view would have to reference that global. This just smells bad. And would > get worse for each model and view you needed in your application. > > I suppose you could maintain some global map of models, but that doesn't > look nice either, it's not that much different from having a pile of global > models. > > This must be a solved problem surely? Could someone point me to the > solution please? Swing or Quil based would be fine but I assume it must be > generally applicable. > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/groups/opt_out. > > > > >
-- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
