Hi Alejandro,

FoxInCloud is indeed a rewrite scenario: a gradual rewrite where you change one piece at a time as opposed to a migration where you change everything at once.

Let me illustrate in a simple case:

Say you have a VFP form holding a container (cnt) holding a commandButton (cmd), and code in cmd.Click().

FAA adapts your code as follows (simplified):

procedure Click
if thisForm.wlHTMLgen && FoxInCloud is generating HTML from the form
  return .T.
endif

... your existing code ...

The above 'return .T.' instruction orders FoxInCloud Application Server to generate a 'standard' JavaScript event handler:

// generated HTML
<button id="form-cnt-cmd" ... > caption </button>

// generated JavaScript
$('form-cnt-cmd').observe('click', FoxInCloud.DOMEvent)

'DOMEvent' is the standard FoxInCloud event handler in FoxInCloud.js: it sends an AJAX request containing the event type ('click'), object id ('form-cnt-cmd') - and many other information such as user ID, modifier key state, etc. - to the FoxInCloud Application Server (FAS).

The request URL is as follows: ...DOMEvent.xxx?event=click&objAddr=form-cnt-cmd&... where 'xxx' is your application's extension mapped to your FoxInCloud Application Server, and 'DOMEvent' is the central server method dispatching all events.

When receiving this request, FAS restores user's context, executes the event method (... your existing code ...), saves user context, identifies the GUI changes, maps to HTML, sends back to FoxInCloud.js for page update.

At this stage, FoxInCloud has rewritten your app's UI in HTML/CSS/JS, and Server still executes VFP code.

In a second step, you rewrite your server code for this particular form in the language of your choice, let's say asp.net for example.

Say you create a central dispatcher method 'DOMEvent.aspx' where you receive the event type and object ID, take care of user's state, and dispatch to whathever sub-method processing this specific event-object pair.

Once all your form server code has migrated to aspx, you just need to set this property in your VFP form:

wlAltServer = .T.

By doing so, FoxInCloud will generate a slightly different JavaScript:

// generated HTML
<button id="form-cnt-cmd" ... >caption</button>

// generated JavaScript
$('form-cnt-cmd').observe('click', FoxInCloud.DOMEventAlt)

You would also set this option in your application's main JavaScript (xxx.js):

altServerExt: 'aspx'

By doing so, FoxInCloud.js's DOMEventAlt() sends an AJAX request to ...DOMEvent.aspx?event=click&objAddr=form-cnt-cmd&..., just by changing the 'xxx' extension into 'aspx'.

Then you migrate each of your forms at your own pace, without ever putting your company at risk.

You end up with a state-of-the-art SPA web application, all AJAX-based, without loosing control on your business KSF.

>Hi Thierry,
>
>I appreciate your and others' recommendation against a rewrite. I fear the project myself. Our motivation for a rewrite is the long term lack of VFP developers.
>
>The problem our app solves is calculating payrolls according to the laws of Panama, which is a complex set of rules that periodically change... to become more complex. The need to solve this business problem is practically eternal, so the useful life of the rewritten program is potentially very long, assuming we keep it current, and we feel it will pay off.
>
>We know the business problem well, better that our competitors, and the smallness of the market makes it unattractive to foreign software companies. We believe we have a few years to complete the rewrite. During that time we will cover our flanks by developing a few add on options with West Wind Connection, mostly report oriented with some data capture. Right now our app is 100% LAN.
>
>We need to make good choices, so I'll be asking many questions:
>
>We'd like to make the rewrite fairly data driven, so the first question is: Does .NET allow the equivalent of VFP's EVALUATE(lcCommand) ?
>
>Thanks for the concern and response.
>
>Alex
>
>>Walter,
>>
>>I share your opinion that the real issue in the OP's project is whether he can complete it.
>>
>>Some interesting reading from Joel Spolsky, CEO of StackOverflow:
>>
>>Things You Should Never Do, Part I by Joel Spolsky
>>
>>How To Survive a Ground-Up Rewrite Without Losing Your Sanity
>>
>>The first, absolutely critical thing to understand about launching a major rewrite is that it's going to take insanely longer than you expect. Even when you try to discount for the usual developer optimism. Here's why:
>>- Migrating the data sucks beyond all belief
>>- It's brutally hard to reduce functional scope
>>- There turn out to be these other system that use "your" data
>>...
>>You you have to totally own the business value.
>>First off, before you start, you must define the business value of this rewrite. I mean, you should always understand the big picture value of what you do (see: Rands Test). But with rewrites, it's often the tech lead, or the developers in general, who are pushing for the rewrite -- and then it's absolutely critical that you understand the value. Because you're going to discover unexpected problems, and have to make compromises, and the whole thing is going to drag on forever. And if, at the end of all that, the Important People who sign your checks don't see much value, it's not going to be a happy day for you.
>>...
>>Worship at the Altar of Incrementalism
>>Over my career, I've come to place a really strong value on figuring out how to break big changes into small, safe, value-generating pieces. It's a sort of meta-design -- designing the process of gradual, safe change.
>>
>>
>>
>>PS:
>>>* Windev
>>>* Servoy
>>>* Lianja
>>*FoxInCloud
>>
>>Would you mind adding FoxInCloud to your list?
>>As a full SaaS platform, FoxInCloud takes in charge user state management across multiple servers, user security, audit trail, detailed execution time reporting, and more.
>>
>>FoxInCloud implements the gradual change approach mentioned earlier.