Yes Thierry.
Like I said I fully understand how complex it is what you're doing, which is why when I originally built the DHTML renderer in Web Connection back in the late 1990's (when it only worked in IE) I decided to discontinue it, even as other Web Browsers started support the original 'DHTML' syntax that IE originally introduced.
It's a perfect fit for a third party to build that bit, because it's a full time job/product that needs to be dedicated to that. For me as a single dev also supporting tons of other stuff in Web Connection (and lots of other tools) there would have just not been enough time to do it. I don't envy the work that goes into building what amounts to a UI library. Building UI frameworks is one of the most thankless jobs I can think of because there are always some edge cases that need to be addressed - it never ends...
Better you than me :-)
+++ Rick ---
>>>I was thinking along the lines of that SCX to dHTML renderer
>>
>>Basically that's FoxInCloud is doing today...
>
>I share this view.
>Beyond adapting a VFP app. to the web, FoxInCloud provides a HTML/CSS/JS clone of a VFP app. UI, and separates the UI and the server (business) layers, allowing to migrate the server code without the users even noticing it.
>If one admits that a responsive web app. is the safest bet for the future, progressively sliding from a desktop app. to a web app. with the server code written in some 'modern' language is a very safe migration option; at least safer than rewriting from scratch.
>
>>The problem with a renderer is that it falls apart very quickly unless there's a lot of external stuff that's specific to the HTML platform. This is why I long ago discontinued work on the original dHtml renderer - it would have been an endless support nightmare trying to make all the crazy combinations of controls and FoxPro behaviors work - especially with people then expecting them to work the same as FoxPro did.
>This is where FoxInCloud picked up where I left off and they are doing basically the hard work of providing the infrastructure to actually produce the HTML and support behavior that has to be available ontop of just the rendered form output. And if you go to their message board you can see what I mean - there are lots and lots of edge cases that need to be addressed - and Thierry and team do a great job of addressing those, but I imagine it's a monumental job. Compared to Web Connection FIC is likely exponentially bigger in terms of scope.
>
>The most difficult issues were:
>
>A FoxInCloud application supports all VFP behaviours except some very seldom used events (eg. .DownClick()), and some classes not suited to a Web display (toolbar, formset, and control that FAA replaces by container because control hides its members).
>
>FoxInCloud tallies about 100k LOC (VFP and JS), was twice as much as WWWC V.5, last version I counted.
>
>>There are a lot of external dependencies to make even standard FoxPro controls work - simple rendering of a form is not enough. FoxInCloud actually provides that with a complete framework that provides the behavior for stock controls plus a host of common activeX controls. You can't do that with **just** HTML rendering and so I don't think having a native HTML renderer is going to really be very useful in the language on its own unless a big effort goes into building a client side support framework (ie. rebuild something similar to FoxInCloud).
>
>Yes, when generating the client side it's important to always think how it'll interact with the server side.
>In FoxInCloud, most changes happen on server side, using original VFP app code. FoxInCloud identifies the UI visual changes and tells the client side what updates are required to keep in sync with server side; orders go to simple HTML controls like input, and much more complex controls like the
ActiveWidgets grid.
>Update responses are a mixture of XML (could be JSON), and JavaScript.
