FoxInCloud views a VFP9 application as a black box interfaced with inputs and outputs: inputs are events that user triggers on the graphic interface, outputs are data supplied back: user interface updates, a file or a report.
FoxInCloud ‘clones’ the application GUI into HTML/CSS/JavaScript, catches user events, transmits events to the Visual FoxPro application running on the server for executing the matching VFP event method.
By comparing the state of user interface before and after event execution, FoxInCloud Application Server (FAS) identifies the differences and sends them back to the client browser for execution on the HTML page.
FoxInCloud hooks applications forms and contained controls through 2 additional layers of classes substitutive to the native Visual FoxPro classes; while the base layer is FoxInCloud-specific and can be replaced at any time by a newer release, you can implement specific code in the intermediate layer dedicated to your app(s).

At startup, FoxInCloud Application Server (FAS) instantiates application's forms and recursively scans containing objects.

FAS maps each member control into HTML/CSS/JavaScript with an ‘ID’ reflecting its position in the containment tree.

Each event implemented in a Visual FoxPro control is also implemented in its HTML counterpart (except some very few VFP events which do not map exactly the same into HTML).

All HTML DOM events are handled by a single standard FoxInCloud JavaScript method: FoxInCloud.DOMEvent().

FoxInCloud.DOMEvent() retrieves id of event’s target object, value chosen by user when applicable, keyboard and mouse status, then transmits these data to the server via AJAX.
Based on object’s HTML ID, FoxInCloud Application Server retrieves a reference to the matching VFP control, and executes the method of the event occurred in the browser's HTML page.

FoxInCloud Application Server (FAS) maintains the state of each form for each user by saving on disk its key properties and the data session where the form operates (either private or default, including buffered data).

Before executing an event on a form, FAS restores the form’s state (properties and data session, see above) for the requesting user based on a 9-character user identifiers carried along requests.
After event execution, FAS saves the same set of properties into a new state file and compares with the previous.
FAS maps each modified visual property into an update instruction in the HTML, CSS and JavaScript syntax. This set of instructions is then returned to client (FoxInCloud.js) for execution on the HTML page contents.

The user state storage delay is adjustable on line; default is 4 weeks.

Application stores user’s choice into a property of the Visual FoxPro form that developer can define; FoxInCloud replicates this property on the matching HTML form automatically. When user closes HTML form, FoxInCloud JavaScript sends user’s choice to FoxInCloud Application Server (FAS). FAS then provides this value to the specified callback method. User’s choice can be of any type: string, number, date, object, etc.

Executing your application within a Visual FoxPro web server drives some easy-to-implement rules:

• Shared resources: as FAS instantiates forms only once for all users and maintains these instances alive, Form.Init() should only execute code depending on parameters or presence of member objects; code that is independent of the user context should be executed by Form.Load().
  Similarly, as Form.Destroy() does not execute when user closes a form, user-dependent code should be moved to Form.Release().
• Stateless: as several FoxInCloud Application Servers may execute in parallel (up to 32 on the same physical server, several server can serve requests in parallel), each request must restore the whole user context on each request. Any property shared between user events must be saved on disk, by adding to the object.wcPropSave property inherited from FoxInCloud base classes, to a _screen or _vfp custom property, or to a public variable.
• Asynchronism: modal forms’ callback code must lie in a separate method of the same form or one of its member objects.

Besides, you have 3 solutions to enhance graphic rendering of your VFP application to a modern Web app.:

• Style Sheet: as visual properties are stored in a CSS file separate from the HTML, any of them may be replaced by a CSS directive using object’s ID or class as CSS selector, stored in application's standard CSS file (xxx.css);
• Custom HTML rendering: each class and object can build its own HTML overriding standard rendering;
• JavaScript: any object or class behavior may be enhanced through additional JavaScript code added to what is generated.

If your application uses a VFP database, as updates can occur either on LAN (desktop) or Web instances of the application, FoxInCloud provides a bi-directional synchronization class between Web and local databases.
This class can be easily integrated into the LAN version of the application.

Application running on VFP data a usually faster than those using a SQL database: as the VFP tables and the application reside on the same machine, the network issues that may happen over a LAN never occur on a Web Application; and the VFP database is completely secure behing the Web App.: no one except the server administrators can access the dbf files.

Independent of application architecture

Secure:

• Data and business logic are protected on the server: only UI orders are transmitted over the wire, client code deals with UI updates only; HTTP requests never include any SQL command.

A great user experience:

• Only updated elements are refreshed (AJAX), the HTML page is visually stable
• When coming back to a form, user retrieves it in the state as of previous connexion
• Generated default HTML 5 / CSS / JS is fully standard, W3C compliant, compatible with any browser.
• App Look & Feel can be easily customized through custom HTML, CSS and/or JS
• Web application behaves the same as legacy desktop app: users are immediatly productive without additional training
• Average server response time is around .5 second

Scalable:

• Memory consumption and response time do not depend on the number of simultaneous users
• Number of objects, containers and events are only limited by available memory
• Up to 32 FoxInCloud Application Servers can run simultaneously on the same machine; based on experience, each Application Servers can serve up to 10 concurrently active users, 320 total