Hi Ken, You raised interesting points, let me give you 2 answers: one short and one detailed.
Short answer: *see it by yourself!* - See our video showcase on FoxInCloud home page http://foxincloud.com/ Showcased application has: * 63 Forms * 2,482 Objects instantiated * 1,431 Events implemented * 35 reports * a PostGreSQL database (not mandatory, would work exactly the same with a VFP database) and more... - Analyze your application with FoxInCloud Adaptation Assistant (FAA) you can download and use FAA for free: http://foxincloud.com/download.php When you enter the adaptation process, FAA installs over 500 free bullet-proof VFP utilities that you are free to use in your own applications. On http://foxincloud.com/shared-projects.php you can see analysis results for over 340 applications tallying 10M instructions ... Average adaptation ratio is currently 1.72 %. Detailed answer on (1) principles and (2) your specific points: (1) FoxInCloud principles As explained on http://foxincloud.com/techno.php, FoxInCloud acts as a wrapper around your application. FoxInCloud kinda "tears off" your application's UI, clones it in HTML and, most important, preserves the wiring between UI and business logic, namely Events and UI state: - Events: events implemented in the VFP app are mapped to the HTML DOM event model. When user raises an event in the HTML UI, FoxInCloud standard javascript just routes it to the FoxInCloud Application Server, which executes the corresponding VFP event method just as if user had triggered the event in a LAN context; - UI state: FoxInCloud Application Server compares form's state before and after event, and sends back the corresponding HTML DOM update orders to FoxInCloud standard javascript. FoxInCloud interacts with your application through a layer of classes: FAA replaces all instances of VFP native classes (form, combobox, etc.) by FoxInCloud classes based on native classes; no matter how many layers of classes your application may have, FAA just adds a 'ground level' underneath and moves each application class one store up. One important thing to understand is that FoxInCloud Application Server keeps a single instance of each form for *every users*, and keeps track of each user's state for each form in a free VFP table. On each request, form's state is swapped for current user and saved after request. Another generic point is that your application only needs to be *adapted* to FoxInCloud; once adapted, it keeps working in LAN mode like today. It brings 2 important benefits: 1- users can work on either version (LAN or Web) with exactly the same experience; they are free to choose either one. 2- you manage a single code base, can continue your regular evolutions/maintenance while and after adapting your application (2) Point-by-point > 1. How complex a system can this "translate" to the web? Can it do more > than simple orders/line item CRUD and simple "SET RELATION" style reports? As it is merely a wrapper around your application (dealing with events on one end, UI updates on the other end), FoxInCloud does not care what your application does and how it updates data. > 2. Does it require a VFP design that uses form data environments and > controls bound to data or can it handle a 3 or 4 tier design? <Same as above> As FoxInCloud saves user's state for each form, and swaps before and after request, it is more convenient to have form working in a private dataSession; Global datasession is supported but in this case you need to tell FoxInCloud which aliases form uses and/or updates (in a form property). Default datasession is of course supported for child forms working in their parent form's datasession. > 3. Does it expect the VFP system to use buffering? <Same as above> Again, FoxInCloud does not care how you deal with data; all what is needed is to know which cursors your form works. > My application has in excess of 50 forms, many with multiple tabs, often > with dozens of controls on each tab, and many of these forms use two or > three layers of subclassed VFP controls. Several of these forms are tightly > coupled in modeless/modal combinations and they communicate back and forth > with each other. All these features are showcased on our site home page http://foxincloud.com/ You may also check out http://zenbuyer.com/ws/pcpsliders.asp ... click on a pencil appearing when you hover a product ... you will see a child form with a 8-page pageframe, over 500 objects, save, cancel, image upload, etc. The number of class layers in your application does not really matter; FoxInCloud will add 2 layers underneath; we currently work with 7 layers of classes without noticeable impact on performance. > I never use grids--especially not for data-entry. :) I have a very flexible > listbox-based control class with lots of grid-like features that I use for > picklists. FoxInCloud supports in-grid edition but you may prefer something else ... If your picklist lies in a child form, you just need to store the result in some form's property and declare this property name at design time in a form property named 'wcModalChoiceProp' (FoxInCloud default is 'wuValue', you can specify another one) > I never bind data to controls; I have code routines in my business objects > that transfer data back and forth between GUI objects and the data I/O > layer so that all validation occurs in business objects and nothing gets > irrevocably changed before being checked and validated. Thus nothing has to > be "reverted". Whether your data is stored in properties or a cursor, FoxInCloud will automatically save and restore them on each user request. > Much of the control layout in my main data-entry form is user-configurable > and dynamically derived from data in tables at runtime. FoxInCloud manages user identification through 2 methods you need to implement somewhere in your subclasses of FoxInCloud: - wUserSet(<userID>) - wUserGet() FoxInCloud executes wUserSet(<userID>) before each request to let your application know which user is involved. Your implementation of wUserSet() can do whatever chore is required to setup user profile (such as seek(), storing user ID in a _Screen.property or a PUBLIC variable, calculate a user right string, etc.) wUserGet() should return current user's ID so that FoxInCloud can store it and feed it back into wUserSet() on next request. Any type of User ID is supported, mainly I or C FoxInCloud also supports impersonation (like an admin borrowing the identity of a specific user) If your control layout is setup in form.init() based on current userID, it'll work in Web just like it does in LAN. > I have a filtering/reporting/querying system that the user can customize to > create hundreds of combinations of filters/queries on the data. As long as you have a user interface interacting with some data storage, this will work in Web mode just like in Lan mode. > I have several very complex reports--all of them are munged in code to > produce flat file tables that the report writer just spits out; I don't use > the VFP report writer to configure reports very much at all. The only point worth caring of is the duration for producing these reports; if report generation is quite long, you have several solutions on hand: - either run several FoxInCloud Application Servers so that, if one server is busy producing the report, you still have one or two separate server for interactive requests. (FoxInCloud supports up to 32 servers) - either create an asynchronous process with callbacks if your reports runs through multiple steps: user will see report progress just as in LAN mode. > The application has complex menus and many features and plug-in modules > whose availability and behavior are determined by a complex user rights and > permissions system, much of which is dynamically generated from tables at > run-time. This is something we have addressed in the showcased application, though the showcase does not explicitly show it. Up to now, we have an Excel template where you can define your menu items with the following fields: - Pad Name - Pad Caption (expression) - Bar Caption (expression) - VISIBLE FOR (expression) - SKIP FOR (expression) - Form (expression) - Top Level Form? (expression) All (expression) are evaluated at run time, so you can rely on user profile to decide what to display and enable. Of course menu is rebuild each time a page (top level form) is built, so menu content is totally dynamic. > My code is distributed across several framework classes (both .vcx and > .prg) and several application-specific classes and subclasses (also both > .vcx and .prg), as well as .scx forms. FoxInCloud supports *.vcx, *.prg and *.scx > Most of my data is on the server but there are some critical tables that > are on each user's workstation. One of FoxInCloud clients has done something similar for an app serving various clients with different VFP databases; in wUserSet(), he has simply opened the proper dbc and tables based on userID. > I designed the application in four tiers (GUI, business objects, data I/O, > database) to eventually be ported to a client-server situation. I never > ended up doing the port but the framework and application are stateless > even though they still only interact with VFP data over a LAN. Since VFP > buffering works poorly, if at all, in such situations, I created my own > hand-made buffering code. My referential integrity rules are also > hand-coded because they are way too complex to work with little lines and > pictures or SQL key commands. Again, FoxinCloud does not really cares how your application works internally; it just executes events, maintains user's state and identifies which UI changes are to be applied on the HTML page. > I just have a hunch that the 98% figure decreases considerably as the > complexity of the application increases. On http://foxincloud.com/shared-projects.php you can see analysis results for over 340 applications tallying 10M instructions ... Average adaptation ratio is currently 1.72 %. You may also see what happens for your own application by running FoxInCloud Adaptation Assistant (FAA) against it; FAA is totally free to download and use : http://foxincloud.com/download.php Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/ _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
