YAF Mojito Initial Design Meeting Video Transcript
- Unified JS web app stack for developers.
- Developers means our users. [Drew]
- What developer has to do is very similar between Y.App and Mojito (once we've finished convergence). [Drew].
- No ambiguity between what the developer should be doing re: YAF or Mojito, it's all building toward single stack. [Eric].
- First goal is that developer approach converges. [Drew]
- Second goal is that code converges as well. [Drew]
- Enable partial-page reload on client-side. [Drew]
- Mojito uses as much of YUI code as we can. [Drew]
- Mojito becomes a thin layer on top of YUI App Framework. [Drew]
+--------------------------------------------------------------+
| |
| +-------------------------------+ +------------+ |
| | +----------+ +----------+ | | | |
| | | Template | | | Template | | <- select - | Controller | |
| | +----------+ +----------+ | | | |
| +-------------------------------+ +------------+ |
| ^ ^ |
| | | |
| | on(change) |
| | | |
| | +------------+ |
| | | Model | |
| | +------------+ |
| | |
+--------|-----------------------------------------------------+
|
| template.getContent
|
+---------------+ +--------------------+
| Renderer | <---------------------- | Mojito Framework |
+---------------+ mojit.render +--------------------+
- Controller uses zero or more Models. [Drew]
- Controller listens for change events fired by the Model. [Drew]
- Controller then chooses Template (currently called a View). [Drew]
- Mojito framework then Renders the template. [Drew]
- So the only only change here is introducing Models that when we have changes to the data we can detect it. [Caridy]
+--------------------------------------------------------------+
| |
| +-------------------------------+ +------------+ |
| | +----------+ +----------+ | | | |
| | | Template | | | Template | | <- select - | Controller | |
| | +----------+ +----------+ | / | | |
| +-------------------------------+ / +------------+ |
| ^ on(save) ^ |
| | / | |
| | +---------------------------+ ---on(change) |
| | | +--------+ +--------+ | / | |
| | | | Binder | | | Binder | | / +------------+ |
| | | +--------+ +--------+ |<- | Model | |
| | +---------------------------+ +------------+ |
| | | |
+--------|--------------------------|--------------------------+
| |
| template.getContent |
| |
| ------------this.render
| /
+---------------+ +--------------------+
| Renderer | <---------------------- | Mojito Framework |
+---------------+ mojit.render +--------------------+
On the client side what's new is the Binders of course. Two main things...
- A Model can fire an event and that event bubbles up to the Binder. So that's how Binders can react to model changes and then possibly update some element of the DOM. [Drew]
- We wanted to make it events bubbling up to the Binder so the Binder can't change the Model. Can't do any write() operation on the Model. [Drew]
- The other thing is the Binder fires Mojit-specific events that bubble up to the Controller. So that's how the Binder communicates with the Controller. [Drew]
- But it does not have a direct reference to the Controller. [Eric]
- The Binder being responsible for attaching a Click listener to a button and then that click initiates a more Mojit-specific action like "Save"... It's up to the controller to respond to that event. [Eric]
- View is becoming Template right? [Ren] .. Yes [Drew]
- Binder may get renamed to View. The current Y.View is very close to a Binder. [Drew]
- The Template/Controller/Binder are what developers will typically do, they may also do Model.
- The idea is the Binder stays client-side only. Because of events there's a decoupling so the Controller doesn't have to handle differences on the server vs the client. [Eric]
- We're actually using YAF Binder, Model, View, Renderer, and the controller is written by the application developer, but the Mojito framework uses the YUI framework. [Drew]
-
This next slide introduces a new "app level model" concept [Caridy].
-
A mojit can use zero or more Models depending on the mojit [Drew].
Model (App Level) Model (Mojit Level)
Application Data Structure Mojit Data Structure Data Logic Data Logic Data Sync Data Sync
application.json models created by a mojit controller pushed into mojit via specs managed by controller shared between mojits local to a single mojit represent frame state (or part) represent mojit state (or part) serialized on server (always) serialized on server if persistent restored on client (always) restored on client if persistent used to rehydrate client frame
usually Y.Model instance
models: { model-one: { class: "Y.ModelUsers" config: { appid: "xxx-yyy", url: "http://yql/..." } } }
specs: { foo: { type: "FooMojit", models: { users: "model-one" } } }
- I think you can accomplish the same thing by using an addon [Ric].
- Is there a way to make this more lightweight? [Ren]
- Feedback from users has been Mojito is configuration-heavy. Is there a way to do this more conventionally? [Ren]
- If the model is created by an addon then the controller "asks" for the model [Drew].
- Control Logic
- Manages Models (proposed)
- Chooses template
- Chooses view
- Builds URL
- Proposes new URL.
- No particularly interesting bits here, a few potential api names.
- Today controller methods combine both actions and utility methods. [Drew]
- Having the Controller respond to events is what leads to actions, actions are events. [Drew]
- It's the framework that sets up the Controller as a bubble target from the Binder. These are YUI Custom Events. [Eric]
- Do you see Model events follow this path as well? [Ric] Potentially yes. [Drew]
- We're thinking this is the current Custom Event system? We should question whether we need the entire thing, because it's where a lot of the overhead might be (with stop propagation or prevent default stuff). [Satyen]
- Might have multiple binders for a single Controller [Eric].
- It will still go through dispatch() [Drew/Ric]
- Frame Structure
- Mojit Instance Configuration
- Fires actions on a Frame (proposed)
- Builds URL
-
UI Logic
-
Listens to UI Events
-
Fires Mojit Events (proposed)
-
Reacts To Model Changes (proposed)
-
Manages DOM Structure
-
Converge to Y.Binder (proposed)
-
How does the view establish listening to the Model? [Ric]
-
The controller knows the models for each mojit and the binder will listen to all of them [Drew/Caridy]
- HTML markup
-
One handler per mojit
-
Invokes/dispatches actions into a mojit instance.
-
Serializes global models used by a mojit.
-
Restores globel models used by a mojit.
-
We don't know if the Handler resembles MojitProxy or not. [Caridy]
-
It probably doesn't [Drew]
-
Applies data to a template.
-
Manages template engine helpers.
-
Base implementation from Y.Renderer
-
Some rendering engines like handlebars have "helpers" so there's a kind of a bit of decoupling here. There's also the potential for a Mojit to define your own renderer. [Drew]
- Controller addons
- RS addons
- Page addons ???
- Binder addons ??? (addons for everything basically)
- Existing middleware changes to Y.Router per-path middleware.
- API is very nearly identical (AAK req, res, next)
- going away
- ac addons become controller addons
- controller calls into fw view 'mojito' addon
-
new, has lifetime of page request
-
short-lived on server
-
long-lived on client
-
available in controller
-
(possibly an addon location)
-
One of the tenents of Mojito is that any time you run a Mojit you have to provide the entire context since it might be running in an entirely unique node.
-
Backward Compatibility?
-
Performance Is PARAMOUNT [Ric]