servGAE
(service in module tri
)
servGAE provides the interface to its counterpart on the server which presently is the Google App Engine.
The datastore and security services are described in Server Interface.
Should it be necessary to replace interface there are 2 strategies that should work:
Replace the methods in this service by those that exhibit the same signatures and functionality. Behind the scenes a totally different interface could be used.
Replace the interface on the server that takes the same JSON interface requests and that returns the same JSON object constructs. Where more in depth datails are required than given in this document the logging function could be used on the Apps system to get use cases for each type of request.
Tests whether the sUser and sPW match that of the SuperUser record.
It matched an AdminUser record is created. The oNew properties User and NewPassword are used
for the AdminUser properties. It is created for app ID oNew.AppID
It uses the SuperUser Command Set.ajaxAddAdminUser to accomplish this.
oNew – {Object} –
Object containing AppID, User and NewPassword properties.
sUser – {String} –
SuperUser ID
sPW – {String} –
SuperUser password
fOK – {Function} –
callback routine for successful match
fFail – {Function} –
callback routine for failed match
The changePassword function changes the logged in user password to the new value.
Note: Passwords must contain at least one alphabetic character to distinguish them from the encrypted value stored on the server.
See Server Interface for more details on this process.
If the update process fails on the server an indication as to why is returned in the JSON response.
sOld – {string} –
The record type
sNew – {string} –
The key name
fOK – {Function} –
callback routine for successful update
fFail – {Function} –
callback routine for failed update
The dropObj function is ued to remove 'TBL' mode records from the system. It is not valid for 'REC' mode records as it would
remove a whole collection of records. See Record Storage.
The physical key (GekID) used is extracted from the oObj to actually address the Data Object to be deleted.
Once deleted the record cannot be recovered from the server.
See Server Interface for more details on this process.
If the dropObj process fails on the server an indication as to why is returned in the JSON response.
oObj – {Object} –
The Data Object previously retrieved.
fOK – {Function} –
callback routine for successful retrieval
fFail – {Function} –
callback routine for failed retrieval
Returns the value set with setCust. See Server Interface
for more details on this value.
{string}
– The customer (application) name
The getKeyData function retrieves a record ('TBL' mode) or group of records ('REC" mode) from server in JSON format.
The key used to actually address the required data is constructed on the server from 3 parts each separated by a '/'.
See Server Interface for more details on this process.
If the retrieval process fails on the server an indication as to why is returned in the JSON response.
sType – {string} –
The record type
sKey – {string} –
The key name
fOK – {Function} –
callback routine for successful retrieval
fFail – {Function} –
callback routine for failed retrieval
Returns the value set with setToken. See Server Interface
for more details on this value.
{string}
– The token value returned from the login function
Returns the internal URL used to access the AJAX services in the server and established with setURL.
{string}
– url The URL to access the server AJAX services.
The issueKeyData function retrieves a record header or array of record headers that describe the complete record key, its update datestamp an its internal physical key (GekID).
The key used to actually address the required data is constructed on the server from 3 parts each separated by a '/'.
It can be used to retrieve a specific record (sRecType == null) or a collection of record headers.
See Server Interface for more details on this process.
If the retrieval process fails on the server an indication as to why is returned in the JSON response.
sType – {string} –
The record type. Null indicates User profile data (Admin authority required by logged in user)
sRecKey – {string} –
The record key (suffixed with '%' to get an array of matching records).
fOK – {Function} –
callback routine for successful retrieval
fFail – {Function} –
callback routine for failed retrieval
Tests whether the sUser and sPW match that of the SuperUser record.
It matched a list of the applications is returned in the response object.
It uses the SuperUser Command Set.ajaxListApps to accomplish this.
sUser – {String} –
SuperUser ID
sPW – {String} –
SuperUser password
fOK – {Function} –
callback routine for successful match and list
fFail – {Function} –
callback routine for failed match and list
The login function establishes the User credentials and returns a token that is used for all requests
See Server Interface for more details on this process.
The system supports a 2 person login, internally referred to as a double login. This requirement is usually triggered by using the template system to alter 'SINGLE' to 'DOUBLE'. See Deps.js in the Apps system. Its use case is where donation money is counted and two persons must be present.
The double login requirement is conveyed to the server by xUser being an Object rather than a string. The object contains
the string properties user, password1, user2 and password2.
If the validation process fails on the server an indication as to why is returned in the JSON response.
xUser – {Object} –
Userid(s)
sPW – {string} –
password
fOK – {Function} –
callback routine for successful login
fFail – {Function} –
callback routine for failed login
Primes the Datastore using the SuperUser Command Set.ajaxPrimeStore.
The SuperUser record built uses the provided sUser and sPW
sUser – {String} –
SuperUser ID
sPW – {String} –
SuperUser password
fOK – {Function} –
callback routine for successful operation
fFail – {Function} –
callback routine for failed operation
The putKeyData function stores a record ('TBL' mode) or group of records ('REC" mode) on the server in JSON stringized format.
When a record is retrieved the timestamp associated with the record on the server is also retrieved. The server uses this to establish whether stale data is being returned. (ie - an update from another computer happened). In this case the operation fails. In the future for 'REC' mode operations the server will attempt to update the individual data object if there is no conflict.
The key used to actually address the required data is constructed on the server from 3 parts each separated by a '/'.
See Server Interface for more details on this process.
If the retrieval process fails on the server an indication as to why is returned in the JSON response.
sType – {string} –
The record type
sKey – {string} –
The key name
sStr – {string} –
The data to store plus control information (Stringized JSON object)
fOK – {Function} –
callback routine for successful retrieval
fFail – {Function} –
callback routine for failed retrieval
The sendReminder function will send notification to a user using an email address found in the user profile.
Note: This is not implemented at present.
If the process fails on the server an indication as to why is returned in the JSON response.
sUser – {string} –
The userid
fOK – {Function} –
callback routine for successful process
fFail – {Function} –
callback routine for failed process
Sets the internal sCust value used as the 1st part of the multi-part key. See Server Interface
for more details on this value.
cust – {string} –
The customer (application) name
Sets the internal sToken value used to validate all server requests. See Server Interface
for more details on this value.
token – {string} –
The token value returned from the login function
Sets the internal URL used to access the AJAX services in the server.
url – {string} –
The URL where the server is located. This icludes the 'ajax.ajax' method flags required by the present server inplementation.
The prefix of the url passed to this routine is obtained from startup routines. Either the static reference used to load the system is used
or if a 'file//:' is detected
it defaults to localHost:8884. The latter is used in a development environment.
Tests whether the sUser and sPW match that of the SuperUser record. It
uses the SuperUser Command Set.ajaxSuperLogin to perform this test.
sUser – {String} –
SuperUser ID
sPW – {String} –
SuperUser password
fOK – {Function} –
callback routine for successful match
fFail – {Function} –
callback routine for failed match
Tests whether the Datastore is primed using the SuperUser Command Set.ajaxValidateStore.
fOK – {Function} –
callback routine for successful validation
fFail – {Function} –
callback routine for failed validation
The login function stores the returned server token in localStorage. When a browser revisits the site hosting the Triangular application
the localStorage is checked for a copy of the token. If found, validateToken function establishes whether the token is still valid.
The more common reasons for failure include:
See Server Interface for more details on this process.
If the validation process fails on the server an indication as to why is returned in the JSON response.
user – {string} –
Userid (first in double login context)
token – {string} –
from previous login
fOK – {Function} –
callback routine for successful validation
fFail – {Function} –
callback routine for failed validation