These are chat archives for flow-stack/flow

13th
Jan 2015
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:11
@/all I'm extracting the MVC out of flow and I'm making it an independent Amber library
@HeSe showThen: aBlock is pretty much the same expression than showAfter: aBlock and the JavaScript world is pretty familiar to the notion that using a then might have a thennable involved (thennables are objects that comply with the promise protocol)
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:18
I'm sticking to showThen: so far :)
showThen: aBlock "Shows this controller and get aBlock executed after its view is set."
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:19
I would rather say showCanvasThen: or afterShowThen:
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:19
why show canvas? what the canvas has to do here?
but after show does not properly suggest the unhide
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:20
In fact is something already "shown" in the browser at the time before the block is executed? Would a renderThen: be more suitable?
showTemplateThenInitializeWith:
canvas is wrong
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:21
ok let me see that
that kind of suck. I'm tempted to make the #show return the deferred so you can tell it then: yourself
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:22
We only need this functionality to make sure that the template and model structure is setup before we go on with the content of the block... showThen is so general, that is will be forgotten most of the time,... just like "allowJSCalls"
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:22
I do like things to be explicit but I appreciate brevity too
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:23
It must be memorizeable and understandable for beginners ,too.
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:23
if you think that's problem we could do something clever
we could use it only in TemplateController
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:24
like a postRender?
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:24
and assume that concrete controllers will have as good practice to prepare its children in one shot
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:24
postOpenInitialization...
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:24
so we do:
TemplateController>>createChildren <- subclasses override that
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:25
okay
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:25
and we make TemplateController>>show super showThen:[self createChildren]
if the children are bindables then they will do the same with their own children and life is good
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:28
why the then then?
show super show. self createChildren
or rather showChildren
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:30
1 create is because is more general, you can create and keep hidden until the right time to show (think a modal or a notification thing or a feedback whatever)
2 the then is because is has to be after the view has arrived (on promise resolved)
makes sense?
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:32
ok
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:32
ah maybe we have to go to what I've asked first then
about separating creating from display
we might very well do a create and createThen:
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:33
that is what I think too. There must be a create, initialize, show strategy
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:33
this is getting pretty Dolphin Smalltalk
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:33
and a postShow/OpenInitialization
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:33
where Presenter>>createComponents was an initialization method to create the children
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:36
What is the case? We want to show a template controller. Therefore it has to render the html template. Then we have all id's in place and can tell all subControllers to render their templates to the according ids. Then we allow the controller and subcontrollers to do fancy stuff to all parts rendered based on the current state of the model. Like hide / show parts,....
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:37
and they to their children yes
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:37
yup,... and the root controller has the last word
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:38
ok, this release is stays like this
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:38
this is why I would show, then postInitialize and in between defer
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:38
but we we'll be moving into that design direction
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:38
ok
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:39
you are calling post initialize to the actions that comes after the view gets set?
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:40
I would say, yes... I mean,... a external library can only access an id to do fancy stuff once it is set
I mean the view is set
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:43
yeah but think wider
some times is the model who comes later (from the api for example)
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:45
so signals then?
like showThenSignalReady
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:45
we already have events
#onAfterModel #onAfterView and a couple of others
and we have the deferred that resolves on view
we might need to have another deferred for the model =/
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:47
and show with TemplateControllers
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:47
promises feel better than events because promises will resolve once
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:47
You are right
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:47
they can pretend they are an ordinary message send
I'm publishing amber-mvc#0.1.11
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:49
thanks
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:49
is live
with changelog.md and all :D
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:52
showContainerThen: or showTemplateThen: that would be more obvious
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:53
the thing is I've implemented #showThen: all the way up in Controller
if it would be only for TemplateControllers it might
but it would leave out ListController for example and/or break polimorphism
Sebastian Heidbrink
@HeSe
Jan 13 2015 23:56
Well, then we should think about a CompositeController and List and TemplateController are sub classes...
Sebastian Sastre
@sebastianconcept
Jan 13 2015 23:57
you have to explain me that idea
I didn't understood that strategy and I'm intrigued