These are chat archives for flow-stack/flow

4th
Dec 2014
Sebastian Sastre
@sebastianconcept
Dec 04 2014 13:56
Hey guys
I'm thinking in adding reactions to the controller in a more "composable" fashion
I found out that it could be convenient to say, to a recently created controller, things like
aSpecificController reactionsAt: #onAfterView add: [ aSpecificController notifySomething ]
Another example for when the model is about to be changed aSpecificController reactionsAt: #onBeforeModel add: [ aSpecificController locallySaveSomething ]
Sebastian Sastre
@sebastianconcept
Dec 04 2014 14:04
and some actions would make the collection of callbacks to be evaluated
Typical example is the TemplateController and its need to use onTemplate: data
we could use initialize to say: self reactionsAt: #onAfterView add: [ 'whatever you want to do after the template got loaded and set as fresh view' ]
Sebastian Sastre
@sebastianconcept
Dec 04 2014 14:57
reactions that I'm having in mind onBeforeView onBeforeRender onBeforeModel onBeforeRemove and all their counterparts with onAfter...
Esteban
@eMaringolo
Dec 04 2014 15:31
What is the difference between a "reaction" and an event?
Sebastian Sastre
@sebastianconcept
Dec 04 2014 15:32
Controller instVars: 'model view reactions otherstuff...'
so reactions there would be a Dictionary with collections of callbacks
Dictionary new at: #onBeforeView put: OrderedCollection new
so each controller would store its own collection of callback that is going to be executed when the view is about to be changed
(same for model and other convenient 'high interest moments' of the controller)
in the other hand.. we could just trigger the event and let the observer to set how it should react
that might actually save us to store an instvar because we're already using jquery's implementation of bind and trigger to achieve that feature
Sebastian Sastre
@sebastianconcept
Dec 04 2014 15:38
I'll do a test using just events
if we can keep the controller lean that's for sure is better
Esteban
@eMaringolo
Dec 04 2014 15:40
Ok ok, reactions are callbacks
That was my question.
Sebastian Sastre
@sebastianconcept
Dec 04 2014 15:42
yeah I just exposed that because your question made me rethink :)
so thanks for asking @eMaringolo :)
Esteban
@eMaringolo
Dec 04 2014 15:43
:D
I would define the reactions (I like 'callbacks' better) using traditional event-subscription messages
Sebastian Sastre
@sebastianconcept
Dec 04 2014 15:46
yeah, in event-subscription there is no instVar in the controller dedicated to that
you just do an observation in the initialize or somewhere else
Esteban
@eMaringolo
Dec 04 2014 15:47
so aController on: #eventName evaluate: aValuable withAll: arguments, it's a matter of taste, the end user functionality would be the same. With the option of using a message send instead of a block closure
Sebastian Sastre
@sebastianconcept
Dec 04 2014 15:47
self when: #onBeforeModel: do: [ :m | doSomething ]
Esteban
@eMaringolo
Dec 04 2014 15:47
exactly
Sebastian Sastre
@sebastianconcept
Dec 04 2014 15:47
then.. in the right plce it goes..
self trigger: #onBeforeModel: with: self model
one that is used a lot is the one that gives you callback after the template was loaded and became the new view
Esteban
@eMaringolo
Dec 04 2014 15:50
if those events are synchronous, I'm all in for three-state event triggering, it allows you to hook in the complete lifetime of a MVC triad
Sebastian Sastre
@sebastianconcept
Dec 04 2014 15:51
interesting..
the actual implementation of trigger is in jquery.. lets take a look...
on the other had there is jquery when http://stackoverflow.com/questions/13338484/jquery-trigger-custom-event-synchronously to guarantee that
Esteban
@eMaringolo
Dec 04 2014 15:56
They run in the thread of the event triggerer
Sebastian Sastre
@sebastianconcept
Dec 04 2014 15:57
so is single threaded, the only thing needed is that they use an orderedCollection like colelction of callbacks (which they probably do by using Array)
Esteban
@eMaringolo
Dec 04 2014 16:04
it's the old way of keeping a list of subscribers, and that's for a good reason
so it's fine there is an ordered collection of event subscribers
Sebastian Sastre
@sebastianconcept
Dec 04 2014 16:21
For the record: I'm in the middle of the implementation and I'm removing significant code, which is a great sign
Sebastian Sastre
@sebastianconcept
Dec 04 2014 17:35
Flow refactored and app completely ported to new style
all works after a couple of typos
again a good sign
Sebastian Sastre
@sebastianconcept
Dec 04 2014 23:11
Interestingly, the case of editors (and views) of a model can load in parallel. The model hitting the API and the view loaded by requirejs. The thing is that, for BindingControllers, we need both to be there before asking to bind.