Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

FoxInCloud 4

Status
Not open for further replies.

vj

Programmer
Nov 18, 2000
58
MU
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
 
Audio,

Example,
Real world scenario 1:
We have a huge ERP application that uses all DBF tables, so, we have created a web interface using (not Foxincloud though), FoxWeb. Which we have enabled, eCommerce, Reporting, Making invoices, shopping cart, inventory visibility, credit card integrations using authorize.net and customers can pay their invoices, and interface to the data using secure logins and permissions and other business object rules using pure vfp codes and the interface is of course html/javascripts/css etc..

Scenario 2:
We have another application, a point of sale application, though the backend is 100% MSSQL tables, the retail stores use the desktop application for their POS and transactions and for the online (cloudified piece), its for reporting to the data, and other read/write modules to update tables, prices, etc.. etc..

For 1, its 100% pure vfp dbf and the data is super fast, as the data reside on the same network as the IIS server on a 1GB network.

One of the customers of the ERP have over 3000 customers that access their info in realtime.

Hope that answers your question.

Ez Logic
Michigan
 
What is an ERP?
How does FoxPro create the CSS and JavaScript?

In one of my examples I have a retail store which sells audio products from a trade counter and also sells their products online.
Their local tables contain the relevant data and their website (stock levels and products) is updated hourly via a scheduled task.
The website is a standalone website which works from a MySQL table, updated hourly as mentioned.

What advantage do you gain by it being 100% FoxPro rather than a specific HTML design.

Keith
 
ERP = Enterprise Resource Planning.
Basically a large warehouse management/inventory/customer crm system all in one.

VFP does not create the html nor the css etc.. You write scripts (such as ASP for instance which has VB scripts).
FoxWeb, its a mix of HTML and css and VFP in them.

FoxIntheCloud is another tool you can use as you read in this thread above.

Keith,
here is a sample:

that's pure 100% VFP backend, using VFP DBF and hosted on foxweb server in-house

Ez Logic
Michigan
 
Also Keith, this is their integrated shopping cart. Pulls data, images, prices, everything directly out of VFP inventory table.


So, their customers can shop online, and some come to their warehouse and do walk-in purchase and others order by phone etc.. all integrated, real time, in one system.

that's how we "cloudified" our VFP application.




Ez Logic
Michigan
 
From that description, it looks like I have written several ERP's without actually knowing it.
I assumed, from your earlier description that the system was 100% FoxPro but the server side code has to be created as a separate entity and I also assume that your web images are stored on the server too.

How does the FoxPro App synchronise the product images on the server?


Keith
 
Audio,

You misunderstood me. When i say 100% VFP, I mean, we didn't use any other scripting language to interact with the data except VfP codes and the tables are vfp and everything that handles the data object and businsess logic is vfp codes.

for the web, you cannot use pure language, example, ASP or asp.net or python or etc.. always will have css, html, javascritps, etc.. those are needed to run on browser and on client side.

the backend side is vfp application and vfp web server and data and functions and procedures and classes etc..



Ez Logic
Michigan
 
VJ,
I assume you're still interested in some views regarding your original question.

I do not use foxincloud at the moment.
If I ever wanted or needed to place one of my applications "on the cloud", i WOULD choose FoxinCloud
I base that on some very simple reasons
1 Minimal re-coding
2 Fantastic support from the Foxincloud team.
i.e. When I was experimenting with the product, I got stuck, and asked for help.
Even with a 12 hour time difference, they offered to "log-in" to my pc and check the installation.
And they did log in, and sorted the issue in 5 minutes.

I am extremely disappointed that Mike and Olaff have attacked this product to the extent they have.
Not surprisingly, it has attracted a strong reaction from Thierry.
VJ, the learning curve with Foxincloud is not very steep. You can try before you buy. The trial period is unlimited. I have found the support level beyond reproach.
Give it a try.

 
Someone here probably has spent a lot of time and money to pass from foxpro application to .NET and doesn't accept that a product ca nelp to save time and money to other people so he has no other thing to do to attack this product (foxincloud) without knowing it and this last is the only bad thing. Responding to vj i can only say that with my knowledge of foxpro i can initially had my app on the web (running in a browser) This app used all my old foxpro function i had for my erp. No new code. Now i'm experiencing in html and css but only to understand how to make better pages in my app. I use foxpro tables without problems. My apps works on pc, every kind of tablet on every OS and i have only one form valid each for desktop and for browser....foxinloud support is fantastic.....both for problems (who has no problrms) and even for enanchments......is this a long period solution ? Probably no, but i am not sure of this....Vj test Foxinloud for your app and make your choice. We are here for support...and if you want a demo of one in deployment product ask me nad i'll show it....no speak, show!
 
Hi Keith,

FoxInCloud is based on principles very different from the other 'classical' web development environments.

FoxInCloud Application Server hosts (encapsulates) the VFP desktop application, generates a HTML/CSS/JS UI layer from the VFP forms, captures the granular user events on the HTML 'forms', and runs the VFP event code on the server (including whatever data manipulation with whatever database, VFP or SQL).

With FoxInCloud, the whole logic remains in the VFP desktop code executed on the server in a separate thread, thus hidden from users and 'hackers'; client (browser) code scope is limited to: (1) capture user events (eg. click, change, etc.), (2) send user event (and a reference to the target control) to the server using AJAX (3) get the response from the server which is merely a list of UI changes that the (server) event code has made (4) apply the changes received from server to the HTML page.

Because client-side code can't seriously be protected, having all app-specific logic on the server means a better protection of intellectual property; other Web development environments, even with a framework like Angular, merely implement data binding (the equivalent of .ControlSource), and all the User Interaction and business logic code, coded on the client side, can be copied immediately by any competitor.


Thierry Nivelet (French native speaker)
FoxInCloud, ZenBuyer, IntuiCat
 
Thierry and others: Let me get a few things straight here. I am not attacking the product, I was even advertising it as a choice, also elsewhere.

In his last answer, Thierry, you now focus on the advantages of server side execution of VFP code. It's fine in regard to protecting intellectual property. But that kind of thinking is only half way true. MySQL is a fully open source product and still has a big revenue, this is not depending on closed sources, on the one side. On the other side, in EZLogics case discussed here the main business is selling products, not the shop web app and it's code, also not the data, which is no secret, the products and their stock need to be readable and searchable by customers. In my case a customer won't put up formulas - their core knowledge - to any hosting, not even self hosted.

You explain very good, why response times are an issue with FoxInCloud, every code you put in a VFP form doing things on already loaded data by working on cursors, arrays, collections and controls is done at the client side, when runnning on desktop, and is not involving an SQL server or file server or the network. That is not translated to javascript/ajax, that is now executed at the server side, and that is exactly what I meant. The gain can be, if your application server now is close or even local to data, you can even accelerate the data access as you can with a manually written web application. The typicall client/server nature is positioning core business logic nearer to the data and only UI (html forms) are client side. But you may gain less than you lose, in regard to UI response times you can get much better results by manual conversion or reimplenmentation in client side javascript, disregarding the closed/open source factor. Of course that conversion costs both more time and money. Neither way is a solution for everyone, you have to make that decision per case. Another system typically is needing another interface anyway.

FoxInCloud is very usable, if you can install it on a server with low ping times, because then this effect is not hurting that much, so it's a good thing to use in intranets, for example, as intranets base on an IIS server hosted in the LAN and with a good response/ping time. If you want to use an application global, you have to host it and its data and others have said what they think of that. Some/most clients will be remote users (in the natural meaning of the word). It then depends on what response times are acceptable. For users used to the desktop solution 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. 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.

I didn't and don't say FoxInCloud is for no one, but it has limited use for me and my customers and is no universal solution. I repeat myself, if I add, that it only helps for staying at VFP. It can be a fast solution more than a pain reliever, but in long terms you or your customers won't find someone continuing fox development after your own retirement. Many companies disregarded that fact and still are happily keeping dos apps up and running, so you can also disregard that as a mute argument, but it also caused the downfall of VFP itself and it won't continue forever.

Bye, Olaf.
 
@Keith
So far, FoxInCloud Web Applications are mainly used by SMEs; eg:
group of medical biological laboratories, 20 employees
shipment service auditing and parcel data management: app. 10 employees
veterinary biological laboratories, app. 10 employees

hopefully other FoxInCloud developers can expand on that...
 
User: demo
Password: 1

(this apps is designed to run on mobile devices like ipad, note from 7" to 10"
User: demo
Passsword: 1

These apps are in italian.....
The first has some modules of our Erp and is designed for internal use and for give to customers an access to data as a portal so they can access invoice, technical data and bullettins....

The second app is designed for users who makes works on customer's site so they can have access to all technicla info about the customer and the site......

For both the apps this is the second release, and this is a beta version. The first version is in use since spring 2013.
 
@Olaf.. Back in October, you posted that WPF didn't viable going forward. You need to take another look. LOTS of improvements coming in VS2015.

As a general observation, I'm amazed at the number of people that want a quick fix solution for moving VFP apps to the web or Apple or Android platforms. Quick fix solutions always ALWAYS have many limitations and do a half-baked job.

If you really need your VFP application on another platform, it's time to rewrite.

Craig Berntson
MCSD, Visual C# MVP,
 
@Craig
software rewrite is a complete non-sense:
Things You Should Never Do, Part I
by Joel Spolsky

"... They did it by making the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch. ..."


Joel Spolsky is the founder and CEO of stackexchange.com, the current leader forum provider written in ... .NET
 
The 30 year matured business application I talked earlier about and I maintain for 15 years now, was rewritten twice and both times a success. So it strongly depends on the type of software. Rewriting a browser while competition enhances theirs is a dumb move, yes. There was no competition, as its really custom made and tailored software and the reimplementations weren't just 1:1, but major changes. Admitted we stayed Fox all the time, but the only thing going forward all the time was the data. Rewriting software of that size is the only solution, if not replace it by SAP (ERP) or some other really big system. And that has one major disadvantage: It's the opposite of what companies want. By standardization of a company you lose your unique selling proposition.

Craig, lots of improvements sound good, but also look like lots of changes needing to be addressed, not only optionally enhancements one could use, but things needing to be addressed and deprecating at the same time. This is nothing unusual, but a moving target always is harder to hit. We'll see, as I go forward there. Personally I tend to move to other niches myself.

Bye, Olaf.
 
Olaf,

Times has changed since companies could afford rewriting software. And there is a major difference between moving to another flavor of xBase, and moving to a totally different paradigm such as the web/.net||php compared to desktop/VFP.

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

Or even better take your most pessimistic estimates, multiply by 3 because you're far below the reality (estimates are always far beyond in the same language, they are even farther beyond when moving to another one), divide by the number of clients, do a nice presentation of the benefits they'll get from the rewrite, and ask to each of them to sign the corresponding check.

Read real-life experiences of complete & real re-writes. Read Joel's article carefully, you'll certainly recognize situations where you've run yourself in the past.

My company will never re-write anything. And that's how we've come up with IntuiCat, then Zenbuyer, then FoxInCloud.
 
@foxincloud Joel is taking about rewriting an application from scratch. I once read that on the average an application is rewritten from scratch after four versions. That's VERY costly and a very small percentage of rewrites ever get completed. One thing I specialize in is helping teams to avoid that. Joel is absolutely correct that you should reuse the old, but it should only be reused IF IT'S APPLICABLE. If you randomly pick 100 FoxPro applications, odds are VERY VERY high that all 100 of them have mixed UI code with business logic and data access logic. This does not translate AT ALL to the web.

So, you take Joel's advice and REFACTOR all that out so you have very clean logical layers. However, this leads into the next problem: Ux standards are different from one platform to another and you almost HAVE to rewrite the UI layer. Looking at the FoxInCloud screenshots above and using current web Ux practices, it is all SH*T. Yes, you got your application onto the web in a hurry. Perhaps current users will be happy because everything is familiar. However, it WORKS DIFFERENTLY THAN EVERY OTHER WEB APP ON THE PLANET. If you take it to new users they'll immediately hate it.

But let's take this to a different platform, say you need a native iPad application. Your VFP code won't run AT ALL. You have no choice but to rewrite. So, rewriting sometimes HAS to be done.

One other, related thing... why did the code get into a place of being crap in the first place? The first is because the developer didn't take the time to integrate the new code into the existing code. He just put a big, ugly bandage in place and moved on. The second reason is that management generally only cares about getting the current issue fixed. They don't care about technical debt because its hidden. There's no line on a financial statement that says "Technical Debt is valued at $500,000". It may not be that much, but I guarantee you that ANY company that has written any code has technical debt and it will cost the company at some point.

Craig Berntson
MCSD, Visual C# MVP,
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top