Client Side Documentation

This document explains Yote client side programming. The client side programming experience is meant to have the flavor of object oriented scripting. Javascript ote was written for simplicity of app construction and prototyping. The flavor of client side programming is meant to be the same flavor


Includes

The following scripts should be included in any yote page. Yote relies on jquery and the javascript is not yet minified at the time of this writing.

<script src="/yote/js/jquery-latest.js"></script>
<script src="/yote/js/jquery.cookie.js"></script>
<script src="/yote/js/jquery.base64.min.js"></script>
<script src="/yote/js/json2.js"></script>
<script src="/yote/js/yote.js"></script>
	      

Including these provides $.yote which contains the methods needed to interact with the server.

Connecting Yote

To get started using a yote app, simply invoke init, then get the app singleton object. Each app has a singleton that provides methods for the app and stores information specific to it. Putting all yote code inside the jquery $().ready function is recommended.

$.yote.init(); //connects the front end objects to the backend

//returns the singleton app object.
var app = $.yote.fetch_app( 'MyApp' );
	      

Logins

Some apps do not need to store information on a per user basis, but some do. Yote provides methods to create and manage user accounts and logins. There are four different login related methods attached to the $.yote.

Note: All the handlers below are optional.

var login = $.yote.login( 'handle', 'password', pass_handler, fail_handler );
var login = $.yote.create_login( 'handle', 'password', 'email', pass_handler, fail_handler );
$.yote.remove_login( 'handle', 'password', 'email', pass_handler, fail_handler );
$.yote.logout();
	      

Invoking Methods

All methods on yote objects have the same method signature and take four optional arguments.

var return_value = yote_obj.some_method( 
   parameter,    // this can be undefined, a scalar, a yote object, an array or an object ( hash )
   passhandler,  // this is a function that is invoked upon completion and given the return value as an argument
   failhandler,  // this is a function that is invoked upon error and is passed the error message as an argument
   use_async     // when true, this method is called asyncronously. This must be set true if there are files as parameters
                                       );
	      

How it's done

Client side Yote is programmed in a functional style rather than a templating one. Forms are not used in favor of sending data back to the server using method calls.

Method calls are made synchronously by default. This allows for a more natural programming feel. Method calls can be made asyncronously as well, for the case where the order of communication flows is not related. If the method call takes a file upload as a parameter, the call is automatically made asycnronously.

The general style of programming is to obtain an app object and invoke methods on that app object. Use jquery to listen for UI events and invoke methods as a consequence of those events. The app object will always return the current state of items on the server.

Basic Concepts

Yote core javascript has four main tasks that will be covered in detail in this document. Much of the client side mirrors the server side, so both the server side documentation and the client side documentation will have necessary overlap.

Yote javascript objects are provided with methods that mirror server side methods. Each method attached to a javascript yote object has the same parameter list and all parameters are optional. The methods are called syncronously be default but any may be called asyncronously.

There are a few types of server side objects that always may exist for the system. These objects have special methods that return them. Think of these as the primary building blocks of a yote app.

The Root
The system has a singleton instance of Yote::YoteRoot that serves as the base root. The methods on this object provide all other objects. Every object in the Yote tree trace back to this primary object. Apps and user logins are directly attached here. The root will rarely be interacted with directly; convenience methods are used instead.
User Logins
Uniquely identify one person by their email and handle. Credentials are kept here and passwords are hashed.
User Accounts
One Login has a different account per app just as one person may have an account in different banks. The account holds on to user data that relates to the app in question.
App Objects
The root objects for one app. These objects store user accounts and anything else as devised by the app developer. All public methods of the app on the server side are automatically attached to the javascript object counterpart.

Primary Javascript Methods

$.yote.init()
This method must be called before any other. It attempts to log into the system based on tokens stored on cookies, and returns a login object if successfull.
$.yote.fetch_app( 'perl package name of app' )
This returns a singleton app object that contains all the methods defined on the server side for that app.
$.yote.create_login( handle, password, email, passhandler, failhandler )
Tries to create a login with the credentials supplied. It returns the login created. A pass or fail handler function are optionally passed in. This method sets login token cookies on success.
$.yote.login( handle, password, passhandler, failhandler )
Tries to log in with the credentials supplied. It returns the login object upon success. A pass or fail handler function are optionally passed in. This method sets login token cookies on success.
$.yote.logout()
Invalidates any login tokens on both the client and server side.
$.yote.remove_login( handle, password, email, passhandler, failhandler )
Destroys the login objects. This method requires valid credentials in order to work. A pass or fail handler function are optionally passed in. This method clears server side login token cookies.
$.yote.upload( selector_string_for_single_file_control )
This method does nothing on its own but prep a file_control input for an upload. This method is used as a parameter to a method attached to some Yote object. Using this as a parameter to a yote method call will automatically make that call asyncronous. The server side will see the parameter as a Yote::FileHelper object.
Example : Have the user select two file uploads from controls fileup2 and fileup3. An Upload method has been defined for the upload_app in this case.
	      	upload_app.Upload( 
                   { somevar : 'someval', 
		     somefile : $.yote.upload( '#fileup2' ),
		     somefile_2 : $.yote.upload( '#fileup3' ),
		   },
		   function( msg ) { alert( "Upload successfull : " + msg ); },
                   function( err ) { alert( "Upload failed : " + err ); }
		               );
	      

A yote login is composed of credentials that uniquely identify a user. A yote login is global across all apps. Each app, however, has a different account for every login. The account is a bundle of data that is specific to an app and a user. This distinction is important.

Emails and handles are unique for logins. Login objects are like any other Yote object and any sort of data can be stored in them. There are a number of methods that are attached to the yote objects.

var login = $.yote.create_login( handle, password, email, passhandler, failhandler );
  // handle, password and email are required
  //  passhandler and failhandler are optional functions that are run if
  //  the login creation succeeds or fails.

var login = $.yote.login( handle, password, email, passhandler, failhandler );
  // handle, password and email are required
  //  passhandler and failhandler are optional functions that are run if
  //  the login creation succeeds or fails.
	      
 login.reset_password( { op => oldpassword, p => newpass, p2 => newpassverify } );