FoxInCloud 4

[vj]

Hi Everyone,

Has anyone worked on FoxInCloud ! how good is it ... is it possible to migrate the entire VisualFoxPro Application into FoxInCloud. Could this be the path forward for VFP , coz .. i think it is having problems running on windows 8 ... not sure if it even installs on windows 10.

thankx
vijay

 

[foxincloud]

@Craig,
Despite I've tried very hard to explain the migration strategy behind FoxInCloud over and over, I obviously did not succeed making it clear at least to your mind. And if you've not got it, I doubt anyone else could have got it either.

Let me try one more time with my best English ever ... and still with my French mindset I'm afraid

Here is what FoxInCloud does and allows:

1/ replace the VFP UI by an extensible HTML/CSS/JS UI dealing with the server by AJAX

2/ the server hosts (encapsulates) the VFP desktop application like a black box: events in, UI changes out - how the code is written or structured does not matter at all

At this 1rst stage you have a desktop + a web app without any rewrite - you've just refactored less than 1% of your VFP code to make it web compatible (

http://foxincloud.com/shared-projects.php)

As FoxInCloud generates separate HTML, CSS & JS, you can expand your web app for various devices, orientations and resolutions by CSS & JS overrides.
At this 2nd stage you have a desktop + a web app for any device just with CSS & JS refactoring.

Note: FoxInCloud provides a class to synchronize data between the LAN/desktop version and the Web version (described earlier in this thread)

Then you can start moving your data from dbf to SQL - using CursorAdaptor you can do this by refactoring your data access (this step is probably the most 'one way', 'all-at-once' kinda move)

Once your data has moved to a SQL database, you can replace all the desktop instances by the FoxInCloud-based Web/SQL version.

Finally, you implement transactions doing the same as the original VFP event methods with whatever web tech. you like (.net, php, etc.).
You have both the FoxInCloud-based and the .net|php-based web servers working on the same SQL database (on different IPs, ports and/or sub-domains)

Using FoxinCloud or simply editing the *.js files, you re-direct the various events that FoxInCloud has implemented in the UI files (see samples earlier in the thread) to the new event processing methods you've created.
You can either keep the FoxInCloud HTML UI update mechanism, or any other mechanism you see fit such as Angular (with much more business code on the client); the only 'constraint' is to move one form at a time.

At this 3rd stage you have a web app working in a 'viable' technology without rewriting anything, just moving pieces of UI from FoxInCloud to your target Web platform.

Note that UI remains unchanged during the whole process, from 100% desktop/VFP to 100% web/pure web tech - you avoid constraints such as synchronizing user training and release of new versions.

I hope this can make some sense ...

Thierry Nivelet (French native speaker)
FoxInCloud, ZenBuyer, IntuiCat

http://foxincloud.com/

 

[Olaf Doschke]

>Ask your boss how many of your clients are willing to pay for a complete re-write, and how much.

Lets see. So far everything we got hands on in first stage maintaining got rewritten.

More general, big enterprise applications don't work 1:1 in the web. You state you can change the html/css, but that won't be enough.

Lets look at different application sizes:

Small apps: A rewrite is not very expensive. Done manually and using best practices in whatever new target platform and language you choose, you get the best results. Even small sized companies can afford it.
Enterprise apps: I haven't ever seen the need to put an enterprise application into the web or cloud, those are typically handling very sensitive data you only host in the corporate lan. Either Terminal Services is used or local backends are synced.
Medium Size apps: Here's really the situation it depends and an automatic conversion with few refactorings can make sense. After all your new users would most probably be employees at a new remote location, eg after a merger or acquisition.

The question is, whether you really need some application globally suddenly, I have never seen this case and I see the better option to install it in the same way and link it at the data tier rather than put it into the web at the Ux layer, because it works as is and with the same experience.

Personally and in regard of VFP apps I also rather see the enhancement and migration as a thing, which should not be done a few years behind closed doors, but grow naturally. You can do hybrid application by interoperability and so you can grow a .NET application out of a VFP application, with the only restriction to first stay Winforms. You get earlier feedback of users, and can earlier react to new demands, as the app development doesn't need to freeze during rewrite.

Bye, Olaf.

 

[foxincloud]

Hi Olaf

Thanks for this interesting debate involving contrasted experiences. S/W strategy is an area where YMMV according to existing assets and target market, just as you mention; I won't argue on that.

However you seem to agree that 'rewrite fits all' is rather irrelevant, every specific situation may appeal a specific solution. This might also mean that the migration strategy we propose with FoxInCloud makes sense in your mind in many cases.

About your comparison across company sizes, I often observed that the size of the software is pretty proportional to the size of the organization; a one-man shop uses a couple of forms, more the company grows the more forms you will add to suit every department/service specific needs, and an increasingly complex management information system.

http://foxincloud.com/shared-projects.php

shows that the average # of forms for a VFP app is 37 (60 when excluding projects with less than 5 forms which are probably test projects); the max. # of forms is 1,596.

By the way, I think many people would be interested in seeing practical examples of your application using "hybrid interoperability and so you can grow a .NET application out of a VFP application", running in both desktop and web.

More general, big enterprise applications don't work 1:1 in the web. You state you can change the html/css, but that won't be enough.

Not sure to understand this statement ... neither do I understand the facts behind, and the limitations you've seen.
Changing the html/css/js lets you do everything you want / need / dream on the UI/Ux or whatever other acronym you see fit.
In 15 years of Web development, and 10 years of AJAX development, I've never seen any limitation that could make it 'not enough', especially with today's browsers supporting HTML 5 and CSS 3.

Could you just throw an example so that everyone can understand?

In our experience, with the Web Applications currently in production with FoxInCloud, using the proper optimization techniques and a powerful Web Server, we've found no limitation that would make the use of a VFP form impossible on the Web; not saying user gets the exact same response time as on the desktop, just saying (s)he can use the application within the range of comfort.
Anyway, these current (slight) limits in comfort will gradually fade away, just like the graphical UI catched up with the text-based UI in the 90's. Only those who have invested on the web early enough will reap the benefits of every bit of infrastructure running full speed.



Regarding your earlier post dated 6 Jan 15 9:51, I'm obliged to respond on facts; don't mean to contradict you systematically, just to answer statements about FoxInCloud that do not reflect the reality proven by experience.

you now focus on the advantages of server side execution of VFP code

I don't focus on that, just mention it as a side benefit.

We know that many developers and S/W clients are concerned about what the media has described as 'the cloud means spying and loss of confidentiality'. Any Web App strategy should take this issue seriously.

You explain very good, why response times are an issue with FoxInCloud

Once again, FoxInCloud has absolutely no response time issue, no more than any Web App. system, and less than many Web Apps that I've see so far, including some developed on .Net.
I've posted real-life response times, with detailed explanations and mentioned a research paper showing that FoxInCloud response times are just within the area of comfort.

every code you put in a VFP form

Until the end of the paragraph, I can't understand a single word or idea in this text; sorry, blame on my bad English.

FoxInCloud is very usable, if you can install it on a server with low ping times

This means absolutely nothing in practice.
The FoxInCloud Web Apps currently in production run on regular servers, most of them being private virtual servers, hosted by regular hosting companies, without specific ping times.

dragging & dropping data around, or moving it from one list to another in multiselect with buttons or double click you won't get the same smooth behaviour with FoxinCloud

How can you assert that "you won't get the same smooth behavior with FoxInCloud" without having ever tested a FoxInCloud Web Application? That's beyond what I can imagine ... just an amazing piece of disinformation ...

dragging & dropping: managed at the client side, just the dropping may fire an event to the server, perfectly smooth

moving it from one list to another in multiselect with buttons or double click: here is a video showing the multi-select mover lists experience in a FoxInCloud production application (single click, Shift and Ctrl keys being observed, all processed on the server):

http://youtu.be/dx2JDhFpPQs

Quick question: what do you find not smooth is this experience?

In my case this and an ActiveX ExGrid Treeview is making up much of an enterprise application, which matured for 30 years of continually development failed to work with FoxInCloud and I would have been surprised, if this large project had worked out.

ExGrid Treeview: 1/ do you have any site or reference about this control? Google did not find any ... 2/ As I mentioned earlier we are working on TreeView - TreeView is part of the FoxInCloud roadmap

failed to work with FoxInCloud same as for Mike Lewis, no trace of you in our contact base, no message or question from you, no download of FoxInCloud Application Server - how did you manage to test FoxInCloud?

I repeat myself, if I add, that it (FoxInCloud ndlr) only helps for staying at VFP

No, my earlier post about the migration strategy and the HTML/CSS/JS sample files posted earlier demonstrate the contrary:
FoxInCloud is the first step of a continuous, secured and sustainable migration from desktop/VFP to the Web.

Thierry Nivelet (French native speaker)
FoxInCloud, ZenBuyer, IntuiCat

http://foxincloud.com/

 

[Olaf Doschke]

Just a quick answer on

http://youtu.be/dx2JDhFpPQs

>Quick question: what do you find not smooth is this experience?

Indeed, compared to the desktop experience this is already too slow in my opinion! It won't fit the needs of my users.

Movers have to work instantly. This is a good response time, but still has a short time lack. Others may disagree and already be satisfied with this, but not me. Maybe I demand too high standards, but this is how it is. Combine that with a filter on the options (left list), where users may enter any partial string of the items to filter them, and you have a turnaround time with each keypress from client to server and back.

Another simple example is a grid with thousands of rows (won't argue that's a bad idea for a desktop app anyway) vs paging with 10-20 items per page.

Yes, people using web shops - even enterprise shops like amazon - are used even longer waiting times, but not desktop application users, they are used instant reactions of the forms.

Your example looks fast compared to web standards, but not compared to desktop app standards and while that isn't broken as badly, as users will spend some time thinking about what they want anyway and a few seconds more or less don't play a role in getting your daily work done, but overall this is unsatisfying.

It can be even faster in comparison to remote desktop time lacks of refreshing UI, but you of course get the same UI responsiveness if installing local. The migration goal of hybrid applications is not the web, its still desktop. But once you have a .NET WinForms app with separated tiers it's easy to go to WPF. The need to globally work on central data with the same application can be solved in many ways, the goal ma not be to move to a web app in the end. As said you can install desktop apps everywhere needed and sync data and have the transport fully encrypted from endpoint to endpoint. But once you have a VFP winforms->.net winforms by .net standards you also have moved from whatever quirked code to n tier in .net, you can't prevent having a better OOP architecture, and that means you can also build up a web frontend on that at that stage. It's not necessarily my or the goal, though.

Bye, Olaf.

 

[foxincloud]

Hi Olaf,

Very interesting,

still has a short time lack

I doubt some day Web Apps can be as fast as desktop apps but why not?
We had many doubts in the past that reality proved wrong ... cars will soon no longer need a driver ...

Some future FoxInCloud users argued about this slight difference in response time ... just like a car driver does not want to take public transports because (s)he feels like waisting time ... they ended up changing their mind just because the differences you mentioned have strictly no incidence on overall productivity, and are far outweighed by other advantages such as form loading faster (because server instantiates forms only once, shared by all users).

paging with 10-20 items per page.

FoxInCloud provides a container class that instantaneously turns a regular grid into a paged grid, including sorting on column header left click and filtering on column header right click, and data update (any .recordSource and any buffering).
Dev. just needs to add an instance of this class to the form, cut the grid and paste it into the container.
To be released in the next beta, preview:

http://foxincloud.com/tutotest/wFormStandardPage.tuto?awForm=pagedGrid.scx

So finally you tell us that you rewrite your app for the desktop, OK, meno male ...
by targeting desktop, and unless you develop one version by platform, your app misses non-microsoft devices such as iPad.

Think how easily you can sell and install a web app compared to a desktop app!

Thierry Nivelet (French native speaker)
FoxInCloud, ZenBuyer, IntuiCat

http://foxincloud.com/

 

[Olaf Doschke]

I (we) mainly sell my services, not apps. Custom software development is not depending on quantities of sales but working hours.

Yes, computers can act and react faster than humans, I also agree overall productivity is not endangered, but satisfaction vs frustration. Every time lag from an user interface comes on top of reaction time lags of users.

Bye, Olaf.

 

[NasibKalsi]

Hi VJ:

My suggestion to you is simple. If you are a young developer, complete this assignment however you feel but switch to something else as hinted in the above posts. If you are in my age group, above 50s, then you may keep sticking to VFP and its variants.

Another point, if you have to continue developing with VFP and companion with FoxInCloud, then confirm their long term structure to stay in business.

I do not know anything about FoxInCloud and can not give any feedback.

Nasib