Re: Alternatives To Foxpro

select [{"fname":"] + table.fname as fname, ;
[","lname":] + table.lname as lname from table where something = something into cursor tcursor

select tcursor

copy to sometextfile.csv type csv <-- if you leave the commas out in the select statement.. saving to csv will but them in for you.. [","lname":] would become ["lname":]

vcnt= alltrim(str(reccount()))

response.write( '{"total":'+vcnt+', data:['+filetostr(sometextfile.csv)+']}'

The above creates json faster than all the other ways I've done it in vfp... unless I just need 1 or 2 records.. then I do a SEEK ... SCAN WHILE.. generate the json in the loop.....

I'm sure other people have better.. faster ways... I was just saying that in the past this was faster at creating json than C# in .NET.. but it looks like MVC had many improvements added to it in the ajax/json area.

So I'm sure Rick is right about C# .NET is faster... I just want to see for myself...

I've been using ExtJS 3/4 for 2 years now... works like a charm... If I take just the json produced and run it through jslint... I'ts valid... no trailing comma "that IE doesnt like"

Select "{"+alltrim(field1)+"}," as f1,"{"+alltrim(field2)+"}," as f2 .... etc... into cursor tcursor
vtot=alltrim(str(reccount())...
copy to somefile.txt type.....
response.write('{total:'+vtot+', data:['+filetostr(thetxtfile.txt)+']}')

Uhm... Jim. The code you showed here actually produces invalid JSON. Even if it didn't I don't think this is a good way to create JSON because JSON needs to be encoded. Any special characters like line breaks, quotes and other extended characters will break your JSON and any client side library like jQuery or ExtJS will refuse it.

Yes it's super easy to use string concatenation for many things (like XML) and it's very fast but generally, unless you remember all the spec details that's absolutely the WRONG thing you should ever do or your 'standard compliant data' won't be so standard compliant after all.

In Web Connection you can use wwJsonSerializer or as Grover pointed out you can also use the Craig Boyds JSON serializer FLL...

In fact if you're using Web Connection you should look into the wwJsonService class which is a custom process clas designed to simply turn any method's result into JSON (including cursors):

DEFINE CLASS MyJsonService as wwProcess

*** One time configuration method
FUNCTION JsonCallbacks()

lcMethod = Request.QueryString("Method")

*** Bind Json Method to this wwProcess Class
lotarget= THIS  

*** Instantiate the Json Service
loService = CREATEOBJECT("wwJsonService")

*** Response is ALWAYS JSON unless there's a hard server error 
Response.ContentType = "application/x-javascript"

*** Route to the method in this Process Class specified
lcJSON = loService.CallMethod(Request,loTarget,lcMethod)

*** Write out the result from CallMethod which returns the JSON for the method
*** or a JSON Error object if the call failed
Response.Write( lcJSON )
Response.End()

RETURN
ENDFUNC
*   JsonCallbacks

*** Json Method to call
Function JsonObject()
loObject = CREATEOBJECT("Empty")
ADDPROPERTY(loObject,"cName","Rick")
ADDPROPERTY(loObject,"dEntered",DateTime())
RETURN loObject

*** Json Method to Call
FUNCTION JsonCursor()
Select * from tt_custom into cursor TQuery
RETURN "cursor:TQuery"
ENDFUNC

ENDDEFINE

You can then reach this with a URL like:

JsonService.map?method=JsonCursor
JsonService.map?method=JsonObject

More info here:

wcdocs:_1wu1a33et.htm

Hope this helps,

+++ Rick ---

Thanks for the feedback Rick... Let me ask a question though... Say you have a dateset of 1000 records and you want to send that record set back to the web in Json format. Can you show me the code you'd use to create that Json in C#? I'd like to test it.

I wrote many routines in wconnect to handle all my json creation.. I've also made routines in Classic ASP and ASP.net.. either using ODBC or OLEDB to get the data.... wconnect/foxpro always created the json the fastest...

Select "{"+alltrim(field1)+"}," as f1,"{"+alltrim(field2)+"}," as f2 .... etc... into cursor tcursor
vtot=alltrim(str(reccount())...
copy to somefile.txt type.....
response.write('{total:'+vtot+', data:['+filetostr(thetxtfile.txt)+']}')

This method requires no looping through records and has always beat ASP and ASP.Net ...

I'm doing most of my app dev in javascript now... only need backends to create and send json or sometimes xml via ajax rest calls.. so if C# has a big enough gain over fp then that can be the way to go...

Thanks again for the deedback Rick

Hi JimM,

Glad that FoxPro and Web Connection work well for you. There's no reason to run from VFP for anybody for server side code, unless there are political reasons: Management issues, ability to get people to work on the stuff (and this is the biggest complain I hear), and in the case of really large up scalability (although I think that range is so minimal it almost doesn't count anyway).

I've never seen RAPID APPLICATION DEVELOPMENT when writing C# stuff.. When a company needs something done quick, they could care less what it's written in. Microsoft doesn't even use .NET to write its own products.
I'm glad Google and Apple have surpassed and opened Microsofts eyes. Maybe they'll make some useful Development stuff for Windows 8 and Tablets/Smart devices.

I find that a curious remark. Apple of all platforms has the most stodgy software develepment platform of all with Objective C which is circa 1995 C++ with a proprietary syntax. Apple isn't popular because of the development platform - developers are using it out of necessity because the platform is hughely successful. Google uses Java for almost everything which is roughly equivalent to .NET. Google of course focuses on Web stuff as well, but they don't really have a platform that's taken off either with lots of attempts that have ultimately failed.

The Web stuff that's popular tends to be stuff that works, runs with low resources and is easy to use. PHP sadly falls in that bucket easiest which IMHO explains its popularity. Ruby is probably next on the list which is sort of like PHP for more serious developers :-) Most of all Web platforms and especially the front end are in complete free fall at the moment. Tools and libraries come and go in rapid succession, with only a few clear winners (namely jQuery).

The bottom line is that Web technology is evolving very slowly and although things are changing rapidly, it's most the process, not the technology. What this means is that most tools have tons of overlap in functionality and features and we're not gaining new features but potentially easier (or just different) ways of doing thing. I'd argue that the server platform matters less and less and the client side - is where most stuff will happen. I also think that Web UIs will eventually replace native device UIs (for phones/tablets) - developers eventually will not put up with building apps for many device platforms.

the only advantage a STATIC language has is, many bugs are caught at compile time. In most cases you need to write way more code to get something done. I've never seen RAPID APPLICATION DEVELOPMENT when writing C# stuff.. When a company needs something done quick, they could care less what it's written in. Microsoft doesn't even use .NET to write its own products.
I'm glad Google and Apple have surpassed and opened Microsofts eyes. Maybe they'll make some useful Development stuff for Windows 8 and Tablets/Smart devices.

Don't underestimate the power of compile time validation. It's extremely powerful. I've done a lot of work in Fox and I've done a lot of work in .NET and I can tell you that my preference is with .NET. Especially .NET 4.0 which has many dynamic feature improvements that let me do many of the things I could do in Fox.

Again I'm not trying to push .NET but I'm saying with the right tools any platform can be made to sing. I spent a lot of time building tools, both in FoxPro and .NET. If you're using Web Connection then you're seeing a result of that with cross-cutting utilities and classes that simplify many, many common tasks. I've done the same for .NET. To me that's the key to productivity. My Fox and .NET toolkits are very similar these days with business objects, large utility libraries of helpers and even if I were writing and app from scratch in Fox it would look very similar in overall structure to one that I'd write in .NET. I'd also argue that the process of doing it is probably going to be faster (for me) in .NET than in Fox, just because the tools and integration are so much better. Plus I have more confidence in that code because of compile time checking (as well as unit tests) to back up my code. The latter i can do in Fox too, but for the former it's runtime failures all the way. This is especially critical for maintenance long after the initial code was written. Believe me, I know as I have lots very complex code that is now going on close to 20 years in Web Connection's core.

One of the big downfalls of FoxPro IMHO, is the tooling. It's hard to keep track of everything involved in projects with FoxPro's primitive project manager and code searching tools. Makes sense - VFP's IDE hasn't changed much in about 15 years even when it was actively developed. Some of the VFPX tooling helps with this but it's still not what I would call ideal.

I've been seriously thinking about building a separate VFP project manager shell to make this easier, but the effort to do this now would be lost since there's too few developers left.

Microsoft doesn't even use .NET to write its own products.

Acutally they do for a lot of things in .NET. Just not all of them because of existing code base. But that's sort of like saying they don't use FoxPro to build system components. After all FoxPro is a Microsoft product too :-). Blend and the entire Expression suite are written in .NET, all the Live applications are .NET. Most of what isn't in .NET (like Office, Visual Studio) is getting a lot of .NET integration but not a complete re-write because that wouldn't make sense from a RoR point of view.

It still blows the doors off anything else for string manipulation.

FoxPro is not particularily fast nor flexible in string manipulation. For raw performance .NET string manipulation is much faster. For features natively there's maybe a slight edge, but again a few tools and helpers fill that need. Plus the .NET RegEx engine is blazing fast which cannot be said for the VBScript RegEx engine we have to use with FoxPro (both for expression parsing and the COM overhead). Markus and I did some benchmarks on this stuff in the early days of .NET 1.1 and .NET beat FoxPro in typical string operations almost in every instance.

Again, not trying to say .NET is better, but trying to dispell some of the myths that there are a lot of things that you can only do well in FoxPro, which is pretty bogus. FoxPro is a great all around language with a huge set of mish mashed commands. That is it's strength but also its weakness. Great if you've been using it for ages and you know the large command set. But for somebody coming in and learning it anew - not so much. FoxPro is a huge mish mash of features and coding styles.

To each its own. I think FoxPro is a great language. I can still use it today as I could before and it still feels familiar and powerful enough to need my needs. But I no longer think that it's the only choice. Neither do I think that of .NET. I've been using Ruby and PHP recently for a few projects and while that feels awkward and hard for now I can see the benefits of those platforms too. Everything has it's ups and downs pluses and minuses.

+++ Rick ---

I've been using Foxpro since Foxbase. I used dBase III until Foxpro 1 came out. Foxpro blew the doors off all other xbase alternatives. Microsoft couldnt compete so they bought Fox Corp. Microsoft could care less about us developers. They only care about the bottom line "money" They have been killing off many of their products and along the way losing developers. Their sorry excuse for why a dynamic language like foxpro couldnt be part of .NET lost many developers. Then all of a sudden they make a DLR for .NET .. lol Then all of a sudden STATIC languages were the way to go. Get real.. the only advantage a STATIC language has is, many bugs are caught at compile time. In most cases you need to write way more code to get something done. I've never seen RAPID APPLICATION DEVELOPMENT when writing C# stuff.. When a company needs something done quick, they could care less what it's written in. Microsoft doesn't even use .NET to write its own products.
I'm glad Google and Apple have surpassed and opened Microsofts eyes. Maybe they'll make some useful Development stuff for Windows 8 and Tablets/Smart devices.

In my opinion JavaScript is more appealing to young developers than learning .NET stuff. It really boils down to a nice looking front end "Javascript manipulating the DOM" making way better looking stuff than .NET generated stuff...

All we need is Javascript / Ajax / Json / and a backend database.. I use Wconnect for my backend.

Wconnect / Foxpro can pump out Json faster than anything else i've tried. I dont see and end to foxpro anytime soon.. It still blows the doors off anything else for string manipulation. The world is not moving in a .NET direction.. It's moving in a "Javascript client - Ajax - Json - Backend" direction. I'll use wconnect until it cant scale for what I need.. and I dont see that happening anytime soon.

Rick Strahl's wconnect Rocks!!!!!!!!! Thanks Rick

Exactly! Although I think Microsoft would mess up any JavaScript framework (like their own AJAX framework) and even if they didn't they probably wouldn't be trusted with it by the younger coders. MS does server side best in my estimation and that can play well in all these scenarios. Ever wonder why all of Microsoft's client side initiatives either fail or are abandoned??

And I think that .NET/C# is fine in these situations and will scale probably as good or better than anything out there on the server side. However, and I agree, it's overkill unless your in the top 5% of web traffic. For everything else, VFP, PHP, etc. would be fine.... (and yes, I know Facebook uses PHP - but they compile it to C for performance reasons...)

I agree with GloverL. I've been building most of me new apps with javascript frameworks.. jQuery... ExtJS 4.. ExtJS 4 Rocks! I think .Net is way overkill for most things. Microsoft is seeing the writing on the wall. With most of the Code being on the Client side... we just need a backend on the server.. wconnect is just fine for creating Json even classic ASP or PHP.. .Nets future may end like silverlight. Microsoft even brought back ODBC into the mix. Hopefully Microsoft comes out with a javascript framework like ExtJS4 and and IDE..

You're sure right there's nothing wrong with VFP compared to stuff that's out there. Just look at PHP - you could argue PHP is even MORE popular than C# or VB.NET pretty easily yet it's NOT based on the .NET Framework and it's not even 64-bit on Windows!!

COM still runs most everything especially at lower levels on Windows. The news of the death of all this including VFP has been pure FUD.

Most development will be done on the client going into the foreseeable future - stuff like jQuery, HTML 5 etc. This is pretty obvious in the market place and all you have to do is look at Windows 8. So it <i>doesn't matter</i> much on the server side what language you use, C# or VFP! They are interchangeable imo.

Hi all,

Over the last few years there have been many discussions to the eventual end of MS Visual Foxpro. There have been several projects sprung up that have attempted to either extend the life of VFP or become an alternative replacement. The replacements have either totally failed or do not resemble VFP in any such way.

The logical evolution for desktop development in Windows appears to be with little question the .NET framework. My biggest bugbear with this is that although I love C# as a language the closest language to VFP is VB.NET and to be honest doesn't come close.

Giving this some long thought I questioned why I would miss VFP. I have totally accepted .NET and C# yet something was missing. From time to time I end up cutting some VFP code for legacy systems that have not migrated yet and then it struck me. Its nothing more than the VFP language itself that I will miss, not VFP. Looking at the roots of this, VFP was based on the DBase language, my initial searches for VFP language alternatives proved pretty fruitless. I specifically wanted to find the language reincarnated in .NET, no joy.

I was so disheartened as I was coming to the realisation we may actually be seeing a death of a language. People could argue the langauge is outdated, but the truth is it isn't really. It's just a language and it can evolve sensibly like any other. There are many other successful dynamic languages like VFP about.

I then thought harder. VFP fell out with Ashton-Tate back in the day over the DBase langauge. If you look at this single fact, the VFP language is truely a Dbase language at its heart. This made me look, and what do you know, there it is, DBase. DBase appears to still exist and under what seems to be something close to its original company. The website is: http://www.dbase.com.

It appears the language still lives on in a more modern way. It is a shame it is not based on .NET, not sure if this is a disadvantage though. My biggest concern is why I have not picked up on this in any forums anywhere when people were looking for VFP alternatives? Is this purely on the basis of the history between VFP and DBase? You would think those days were gone? I'm interested in whether people even realised DBase even still existed? Whether or not I look at this any closer, I'm just humbled by the fact that we have not seen a death of a language. For me that would be a total tradgedy.

What are peoples thoughts on this?

Regards

Richard