With the closer integration of mojito and YUI, as well as the advent of Yahoo-Arrow, mojito needs new examples on how to write code once for client and server so that it can live up to its promises.
At the moment, all our client-side code is dumped in the binders and we hand off any complex stuff to the server which we access via a RESTified data interface. We are however now at the point that we need a more advanced MVC architcture in the client, over and above what the mojitproxy seems to offer according to the mojito Demos. The MojitProxy comes across as a messaging system between mojits, so that they can message each other, rather than making direct object calls on each other and each other's HTML nodes. I see that the ActionContext is now almost completely "common" in affinity.
So is there a demo of how the ac can be used for client side MVC action handling?
The LazyLoader Mojit is almost such an example: it gives us the following in the binder -- i.e. the binder triggers a call to the controller of it's own mojit. This could also be done via MojitProxy events in response to actions on other mojits, right?
I have reimplemented the "render" function of the MojitProxy for our system, which is based on Jade and precompiled Jade-JS on the client (which results in extremely flexible light-weight client code). I presume that client-side view rendering in Mojito works only with Handlebars, right?
Well, this important functionality should definitely be mentioned in two places in the doc:
This is a key feature for single page apps and an aspect that could seriously speed mojito adoption.
Hey @Ronald, soo many questions in a single post. I will try to answer all:
Yes, mojito client side needs some love, and we have been working on a revamped architecture for the client side for few months now, but it is proven to be quite challenging to integrate YAF into the picture, but the good news is: we are getting there and it will be awesome.
No, you can use whatever template engine you want, you just have to create it to follow the API for the integration (@joe wrote an example of EJS engine in the official docs).
If your controller is common or client affinity, you will get "AC" in those actions, just like you do in the server side. There is nothing in AC that ties it to the server. I posted another answer for another question from you where I described the separation between middleware and dispatcher, and "ac" is the reason why that separation exists.
you're right, I should split this into several questions.
The core question is about the meaning of the action context, dispatcher and output handler in the client. I think you have addressed this in your answer in that there is further awesomeness on the way!