>>And what it doesn't show is how maintainable is the code
>
>The code remains in the usual *.prg, *.vcx, *.scx, etc.
>Maintenance is just the same as for the desktop application.
>You can test your application in desktop mode, then web mode; eg copied from my command window:
>do "c:\program files\vfp9\tools\ab\aw\samples\fic\fictuto\tutolan.prg"
>do "c:\program files\vfp9\tools\ab\aw\samples\fic\fictuto\tutotest.prg"
I think there is more to Craigs point then you answer here - at least at the (long) time ago I looked at FIC.
[reordered and put somewhat out of previous context ;-)) ]
>It's intentionally simple, just meant to show how control/events are supported, and how code is adapted.
That was our take as well. While the introduced changes in the code were easy to understand, they were numerous ***and*** un-DRY, which ***is*** expected from a machine generated process. At latest at the point where some of the forms would have to be redesigned for small screened devices, additional code would follow - and then following the trails of machine assisted code droppings would lead to more maintainance due to introduced non-DRY-ness ;-))
The take here was more on the lines "we will cross that river more DRY than after code adaption" by refactoring the original code somewhat to eliminate most of the individual code droppings. But a few hints about already proven successful ways to minimize the added code would have been better. But such an refactoring effort IMO should be added into cost calculation - no fault of the original devs of the app (who could not foresee such an enhancement) or your machine assisted adaption (KISS principle is very good to follow there). Just normal biz, but should be seen and mentioned.
my 0.001€
thomas
