Gentlemen, Just started Geocoding all our customers and interfacing the Google maps to our VFP system here and it is going well in that we can now display interactive graphs of customers/prospects for our sales staff and throw the links to the graphs into the reps Google calendars on their phones/tablets/laptops... so far so good.
However, I have a question and I guess I am being a little lazy here, as I can't be bothered sifting through all the non-useful so called solutions on the net. The example Google API call for Geocoding given here:
https://developers.google.com/maps/documentation/geocoding/start
returns back a JSON response and I want to easily catch this from VFP ideally without showing the web interface.
Any ideas as to the best approach to initiate this data and capture the response? For the maps I have used the approach whereby VFP generates a HTML Page and embeds a map from a list of lat/long co-ordinates that are embedded into the page which works fine as I don't actually receive any data back, unlike the JSON response.
I guess it is going to be a little like the web services that were the rage some time ago .... I stayed away from them.
I would prefer 100% VFP but don't mind going the called C# program if I have to. Any ideas?
Dave
I guess it is going to be a little like the web services that were the rage some time ago .... I stayed away from them.
Well, it *is* a web service, and web services are increasingly fundamental to how the web operates. JSON is essentially just objects in Javascript notation so you need some way of getting that into a format you can work with in VFP, and almost all web services communicate in either JSON or XML.
You need to at the very least be able to send a HTTP request to the Google endpoint, receive a JSON response (and handle any errors), and decode the JSON into a format you can work with. If you want to stay in VFP-land I'd be looking at Rick Strahl's web tools for all that. Otherwise .NET can do all that natively, you could for example create a COM-callable DLL to do it, or just an assembly called with Rick's WWDotNetBridge tool.
I am doing this in SharePoint next month as another visual display of data.
On Thu, Aug 25, 2016 at 9:30 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
I guess it is going to be a little like the web services that were the rage some time ago .... I stayed away from them.
Well, it *is* a web service, and web services are increasingly fundamental to how the web operates. JSON is essentially just objects in Javascript notation so you need some way of getting that into a format you can work with in VFP, and almost all web services communicate in either JSON or XML.
You need to at the very least be able to send a HTTP request to the Google endpoint, receive a JSON response (and handle any errors), and decode the JSON into a format you can work with. If you want to stay in VFP-land I'd be looking at Rick Strahl's web tools for all that. Otherwise .NET can do all that natively, you could for example create a COM-callable DLL to do it, or just an assembly called with Rick's WWDotNetBridge tool.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
Thanks Alan, I have been looking at Rick's software along with Craig Boyd's JSON class, so I was on the right track... it just seems so damned complicated for a simple result.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Alan Bourke Sent: 25 August 2016 15:31 To: profoxtech@leafe.com Subject: Re: VFP Call to Google Geocoding API
I guess it is going to be a little like the web services that were the rage some time ago .... I stayed away from them.
Well, it *is* a web service, and web services are increasingly fundamental to how the web operates. JSON is essentially just objects in Javascript notation so you need some way of getting that into a format you can work with in VFP, and almost all web services communicate in either JSON or XML.
You need to at the very least be able to send a HTTP request to the Google endpoint, receive a JSON response (and handle any errors), and decode the JSON into a format you can work with. If you want to stay in VFP-land I'd be looking at Rick Strahl's web tools for all that. Otherwise .NET can do all that natively, you could for example create a COM-callable DLL to do it, or just an assembly called with Rick's WWDotNetBridge tool.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
Well, it's a lot better than XML for sending hierarchical info over the wire.
On Thu, Aug 25, 2016 at 12:04 PM, Alan Bourke alanpbourke@fastmail.fm wrote:
Well, it's a lot better than XML for sending hierarchical info over the wire.
I do find the curly braces {} get snagged in the ethernet cable a lot less that the pointy arrows <>.
{grin}
This isn't tough outside of VFP.
On Thu, Aug 25, 2016 at 6:13 PM, < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 2016-08-25 10:52, Dave Crozier wrote:
it just seems so damned complicated for a simple result.
That pretty much sums up lots of the web and early DotNet stuff!!!! I swear sometimes it seems like these uber-nerds create things to be so complex simply because they can.
[excessive quoting removed by server]
On Fri, 26 Aug 2016, at 03:26 AM, Stephen Russell wrote:
This isn't tough outside of VFP.
Agreed. It's Javascript objects and very often it's consumed by Javascript, in a few lines of code. Also easy in .Net using Json.net and so forth.
Easy in VFP too:
https://github.com/FoxInCloud/FoxInCloud-AB/
do <path to>/AB.prg
lo = CreateObject('empty') AddProperty(lo, 'toto', 5) AddProperty(lo, 'tata', .F.) AddProperty(lo, 'tutu', 'test') AddProperty(lo, 'titi', CreateObject('empty')) AddProperty(lo.titi, 'toto', 5) AddProperty(lo.titi, 'tata', .F.) AddProperty(lo.titi, 'tutu', 'test') AddProperty(lo.titi, 'titi', CreateObject('empty')) AddProperty(lo.titi.titi, 'toto', 5) AddProperty(lo.titi.titi, 'tata', .F.) AddProperty(lo.titi.titi, 'tutu', 'test')
? m.lo == uValueJS([{"TATA":false,"TITI":{"TATA":false,"TOTO":5,"TUTU":'test',"TITI":{"TATA":false,"TOTO":5,"TUTU":'test'}},"TOTO":5,"TUTU":'test'}])
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
Le 26/08/2016 à 04:26, Stephen Russell a écrit :
This isn't tough outside of VFP.
On Thu, Aug 25, 2016 at 6:13 PM, < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 2016-08-25 10:52, Dave Crozier wrote:
it just seems so damned complicated for a simple result.
That pretty much sums up lots of the web and early DotNet stuff!!!! I swear sometimes it seems like these uber-nerds create things to be so complex simply because they can.
[excessive quoting removed by server]
On Aug 25, 2016, at 6:13 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
That pretty much sums up lots of the web and early DotNet stuff!!!! I swear sometimes it seems like these uber-nerds create things to be so complex simply because they can.
That was always the Microsoft way: take something and make it so complex that you needed their tools to manage it. Look at FrontPage, or what they did to SOAP for the obvious examples.
-- Ed Leafe
On Fri, 26 Aug 2016, at 05:23 PM, Ed Leafe wrote:
On Aug 25, 2016, at 6:13 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
That pretty much sums up lots of the web and early DotNet stuff!!!! I swear sometimes it seems like these uber-nerds create things to be so complex simply because they can.
That was always the Microsoft way: take something and make it so complex that you needed their tools to manage it. Look at FrontPage, or what they did to SOAP for the obvious examples.
-- Ed Leafe
Web development didn't need Microsoft to get itself into its current hellishly complicated state. .NET isn't and wasn't any more complex than any other comparable platform like Java.
Can't be that hard, I use it Al
-----Original Message-----
Web development didn't need Microsoft to get itself into its current hellishly complicated state. .NET isn't and wasn't any more complex than any other comparable platform like Java.
At 16:13 2016-08-25, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2016-08-25 10:52, Dave Crozier wrote:
it just seems so damned complicated for a simple result.
That pretty much sums up lots of the web and early DotNet stuff!!!! I swear sometimes it seems like these uber-nerds create things to be so complex simply because they can.
That is not true, and you should know better.
It is because a simple system does not look nearly as good on a resume or in a bragging session.
Sincerely,
Gene Wirchenko
Hi Dave:
For the JSON part you have an Open Source project on VFPx:
http://vfpx.codeplex.com/wikipage?title=nfJson
Best Regards,
Fernando D. Bozzo.-
2016-08-25 16:05 GMT+02:00 Dave Crozier DaveC@flexipol.co.uk:
Gentlemen, Just started Geocoding all our customers and interfacing the Google maps to our VFP system here and it is going well in that we can now display interactive graphs of customers/prospects for our sales staff and throw the links to the graphs into the reps Google calendars on their phones/tablets/laptops... so far so good.
However, I have a question and I guess I am being a little lazy here, as I can't be bothered sifting through all the non-useful so called solutions on the net. The example Google API call for Geocoding given here:
https://developers.google.com/maps/documentation/geocoding/start
returns back a JSON response and I want to easily catch this from VFP ideally without showing the web interface.
Any ideas as to the best approach to initiate this data and capture the response? For the maps I have used the approach whereby VFP generates a HTML Page and embeds a map from a list of lat/long co-ordinates that are embedded into the page which works fine as I don't actually receive any data back, unlike the JSON response.
I guess it is going to be a little like the web services that were the rage some time ago .... I stayed away from them.
I would prefer 100% VFP but don't mind going the called C# program if I have to. Any ideas?
Dave
[excessive quoting removed by server]
Hey Dave - what happened - you didn't want any answers back from Females in our group here??
:-)
Regards, Kurt Wendt Senior Systems Analyst
Tel. +1-212-747-9100 www.GlobeTax.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Thursday, August 25, 2016 10:06 AM To: profoxtech@leafe.com Subject: VFP Call to Google Geocoding API
Gentlemen, Just started Geocoding all our customers ...
Do you still need a vfp code example of this i lost most the thread
On 25 Aug 2016, at 18:05, Kurt Wendt Kurt_Wendt@globetax.com wrote:
Hey Dave - what happened - you didn't want any answers back from Females in our group here??
:-)
Regards, Kurt Wendt Senior Systems Analyst
Tel. +1-212-747-9100 www.GlobeTax.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Thursday, August 25, 2016 10:06 AM To: profoxtech@leafe.com Subject: VFP Call to Google Geocoding API
Gentlemen, Just started Geocoding all our customers ...
[excessive quoting removed by server]
-
Alan Bourke -
Allen Pollard -
Chris Davis -
Dave Crozier -
Ed Leafe -
Fernando D. Bozzo -
Gene Wirchenko -
Kurt Wendt -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Stephen Russell -
Ted Roche -
Thierry Nivelet