That brings the issue with the model changes up again ;-) I think we must discuss a general new approach..... as a Amber beginner I struggled a lot on why stuff didn't work until I realized that there must be something rendered and known to the DOM until I can tweak it. This is the main issue why most throw Amber away after a short period of time. I think we just need to add a more obvious "flow"
In Smalltalk you are guided by existing frameworks and naming conventions on how to build a ui and it pretty obvious where to put which kind of code. In Amber we are much more dependent on a good "flow" just to make sure you are not forgetting the evel restrictions when both sides need to interact with each other,.... like our Model problem today
Mapless helped here,... maybe we need the same thing for "showing" controllers.... a framework that takes care of it and guides you more through the process of rendering, initializing and showing stuff
well it is diffcult to explain it. Here are the objectves:
I find showThen: a poor naming, since not the whole Controller is shown,... just the outer frame/temaple
I find the fact that I need to take care of such thinkgs like promisses not very good,... since beginners have a hard time to understand it and keep it in mind and I think this is something the framework could handle in most cases.
Amber brings the Smalltalk to the JS,... just have a look how much better the js lib app structuring got with the last release. Flow adds a lot of HTML tempalting and model change propagation to the mix. Now let's add rendeing/showing to it and we jsut need to focus an the beckend then :-D
@sebastianconcept I tried to bring APP.st to the amber-flow package, but somehow the App main start won't disply the page. even though the main.html is loaded.... I assume now the example.htmlk temaples are missing on this level since they are part of amber-mvc... on the other hand I feel like amber-flow needs it's own examples or maybe even just a link to the petshop?