Henrik, Sorry for the late reply, I'm drowned in work right now :-(
I think you can make it work by * adding the state transition code in the model to avoid duplication * using the javascript that is returned by the controller to update the gui For the latter to work, you need to know what has changed. I think you need to 'ask' the model to the changed todos and rerender them in the js, i.e. @activated_todos = @todo.activated_todos In the state transition code, you keep track of the activated todos and return them in the getter method. You will get some issues because the model does not know anything about the current view (which is normal for mvc patterns). So the js could need some logic to filter out those activated todos that are present in the current view. I don't think the home page, project and context pages are impacted, but special views like tag view or stats or search results may need it. Perhaps this could be a good way to refactor recurring todos too and move some logic to determine the next todo from the pattern from the controller into the model... Makes testing more easy I think. Reinier > -----Oorspronkelijk bericht----- > Van: Henrik Bohre [mailto:[email protected]] > Verzonden: maandag 20 juli 2009 16:21 > Aan: Reinier Balt > CC: tracks-discuss > Onderwerp: Re: [Tracks-discuss] Discussion of state machine usage in > Tracks code > > The todo model uses the acts_as_state_machine plugin which makes it > possible to run code at specific events, e.g. when entering completed > state, the completed_at field is set by the state machine model itself > in the entry action. > http://github.com/bohrax/tracks/blob/4497b597e3d090fbc3cffd809320de68e7 > c2894c/app/models/todo.rb#L31 > > I think it would be good to add more functionality in the state > machine model, which is directly related to state changes in order to > prevent duplication of this code in the controller. > > An example is when completing an action. This (now) requires checking > if there are pending actions that should be activated. If this > behavior was added to the model itself, it would not require these > (duplicated) checks in the controller code: > http://github.com/bohrax/tracks/blob/4497b597e3d090fbc3cffd809320de68e7 > c2894c/app/controllers/todos_controller.rb#L169 > http://github.com/bohrax/tracks/blob/4497b597e3d090fbc3cffd809320de68e7 > c2894c/app/controllers/todos_controller.rb#L270 > > The main problem with this approach is that I don't know how to get > data out of the state machine and into the javascript code. Ideally > I'd like to trigger javascript updates from the state machine > transitions. > > It seems to me that the current ajax javascripts are trying to > anticipate model state changes and remake the GUI after that. I > imagine that using FSM state transitions to trigger "the actual > updates" would lead to simpler and more maintainable code. > > > Any thoughts? Please let me know if you want more details and I'll try > to explain better. > > /Henrik > > On Mon, Jul 20, 2009 at 10:14 AM, Reinier Balt<[email protected]> wrote: > > I don't know what you mean. Could you be more specific? > > > > Reinier > > > >> -----Oorspronkelijk bericht----- > >> Van: [email protected] [mailto:tracks- > >> [email protected]] Namens Henrik Bohre > >> Verzonden: zondag 19 juli 2009 19:20 > >> Aan: tracks-discuss > >> Onderwerp: [Tracks-discuss] Discussion of state machine usage in > Tracks > >> code > >> > >> Hi all, > >> > >> When trying to DRY up some code I realized that e.g. completing a > todo > >> from the normal view and the mobile view requires running > >> completion/activation code on both todos_controller#toggle_check and > >> todos_controller#update. > >> > >> I was thinking that it would be nice to add this to the state > machine > >> in the todo model instead, so the model would always be consistent. > >> The problem I face now is how to get information from the state > >> changes in the model to the ajax javascripts. > >> > >> Is this a known problem, and the reason it is not used like this? > >> > >> > >> Best regards, > >> /Henrik > >> _______________________________________________ > >> Tracks-discuss mailing list > >> [email protected] > >> http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss > > > > _______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
