I have been interested in Yahoo! Cocktails (and Node.js) for a while. I have experience buidling a Phonegap application that sends and receives data (signatures, photos, etc) using a .NET backend and I chose Phonegap because of my web dev background.
Does Mojito negate the need to build apps in Phonegap for data synchronisation or is it a narrow use case of intermittent network connectivity? And how does Mojito deal with interrupted requests i.e. prevent duplication of data or losing data altogether?
What does Mojito do to run on mobile devices? E.g. Is it generating a HTML5 Cache-manifest, using localStorage? I read somewhere that it does not degrade the layout so it generating responsive views or something else?
How would a Mojito application be built to be easier to maintain? I am thinking along the lines of MVC. Do I have to bolt angularjs or some other framework on top to keep my sanity as the app evolves.
Mojito doesn't have any features to handle network connectivity issues, use localStorage, deal with duplication of data, or anything like that. You'll have to build that into your application yourself. (Mojito is built on top of YUI, so perhaps you could use some YUI modules to help.) You'll also need to handle layout issues yourself, but again YUI might help.
Which command are you referring to and where can I see the list of Mojito commands?
I think I am most interested in what you mean when you say "work.. on the client". For example I am watching this Yahoo! dev presentation and at about 15 min he talks about how Mojito can adapt to device connectivity or over heating. And I am wondering how.
I am trying to read the docs and I found this Y.mojito.client.pause() From a web dev point of view that is crazy talk (I mean that in a joking way please :-) ) because once the DOM is loaded what is on the page is all I have until another request is made to the server. Does the app pretend to save and load content using its cache and then on Y.mojito.client.resume() opens a connection to the server and updates itself? In which case there must be some kind of sanity check in the business logic or database because not every request is going to be idempotent e.g. POST or DELETE.Or have I got it mixed up? Maybe my model of how the client and server interact is not helping me right now.
Cocktails does sound like a great platform but I am struggling to get my head around it. Thanks for your patience.
If you've installed mojito globally (probably via npm install --global mojito) the mojito commandline will be installed in your path. If you install mojito locally into your app, the commandline is available at ./node_modules/mojito/bin/mojito. You can see all mojito commands by typing mojito help and get help for each command with mojito help <command>, for example mojito help create. The commandline that takes the client-side part of your app and packages it up as an HTML5 app (for use in phonegap etc) is mojito build html5app.
Mojito itself doesn't know how to determine connectivity speed or device heat, but is structured in a way that there's a natural place to plug that information into your mojito app. Each request in a mojito app runs in a "context" which is an arbitrary key:value dictionary that encapsulates the runtime context for that request. Some example keys are "environment" (which could for example be "development", "production", "staging", etc) or "device" (for example "iphone", "ipad", "android"). Out of the box, mojito will set up a few of these for you, but you are definitely encouraged to define your own based on the different considerations you want your app to be sensitive to.
The Y.mojito.client.pause() is actually a mostly-internal method, and may in fact go away in the future. Just as you suspect, it has nothing to do with DOM but instead has to do with the pausing/resuming different tasks inside of the client-side part of mojito. (It's needed for a few situations, but I'm really hoping we can chop out pause()/resume() when we rewrite the client-side.)
Here are some basics of how Mojito work, which will hopefully make things clearer. A mojito app is organized into "mojits", each of which is responsible for creating a section of the page. As well, each mojit is a unit of MVC: each mojito has a controller, at least one view, and zero-or-more models as needed. When mojito runs a mojit, it really runs ("invokes") a method on the controller (which we call "action"). That method of the controller decides what needs to be done (perhaps calling a model), and then returns data to be rendered using a view. The view used is the same name as the method on the controller by default, but the method can decide to use a different view instead if desired. These mojits can run on the server or client, or in only certain locations if you decide that it's better only to run your mojit on the server for example. As well, each mojit can have a "binder" which is a piece of code associated with each view an only runs on the client. (It's pretty similar to Y.View from YUI.) The binder is what responds to user clicks and other interesting events, can can call back into the mojito if needed. One of the things it can do is invoke an action on the controller, and mojito will take care of running the controller, on the client-side if the controller is allowed to run there, or mojito will RPC back to the server to run the controller there if it's not allowed/available on the client. That's part of what we're trying to accomplish with Mojito: you can write your code to a single API and have it run in either client or server, but can still customize/optimize for each environment when you need to do that. One last point: a mojit can be implemented using the "composite" design pattern, where a mojit is actually implemented as a bunch of child mojits. (In fact, this is how a page is made: it's just a single top-level mojit that has a bunch of child mojits for each section of the page.)