Dbf Files on PHP

[Roberto Lopez]

Hi All,

I'm posting this here, because could be of interest for Harbour users.

I'm working in HMGSCRIPT. It is a JavaScript GUI library, created with the goal to allow the programmer use the same logic of desktop applications for web applications.

It handles MySql and dbf files via synchronous xmlhttprequest.

The support for dbf files via PHP scripts is intended for the following situation: Imagine that you have a Harbour based app running in a LAN and shared by various users, and you want to access the same files with a web client. The only thing that you need is to install an AMP server in the machine where the files are located and make the machine available via Internet, then HMGSCRIPT apps and LAN apps could share the same data.

IMPORTANT: I'VE NOT TESTED THE CLASS IN SUCH ENVIRONMENT YET, PLEASE CONSIDER THAT SOME ADJUSTMENTS COULD BE REQUIRED (SPECIALLY REGARDING SHARING AND LOCKING). THERE IS NO SECURITY IMPLEMENTED (YOU MUST DO IT FOR ANY REAL WORLD USE). USE FOR TEST ONLY AND REPORT ANY PROBLEM FOUND ON THIS THREAD. IDEAS AND CODE TO ENHANCE THE CLASS ARE WELCOME.

Since the dbf files support was dropped from PHP standard distributions, I've decided to code from the scratch a new class to do that.

Please, use carefully (specially to write operations) since the code is fully new and must be considered ALPHA.

Operations that set or get the field content handles all  original  dbf data types (character, numeric, logical and date) as strings (See the sample code for more info).

You can download at: http://sourceforge.net/projects/hmgscript/

Regards,

Roberto.

[Rossine]

Hi Roberto,

Great Project. Soon I'll be using it :)

Thank you very much for all the support and time.

Rossine.

[SD]

Dear Roberto Sir:

Seems to be very interesting project. If things can happen in this way, could be a great leap...

Best wishes to you and your HMG team......

Regards,

Swapan Das

[francesco perillo]

On Sat, Aug 4, 2012 at 7:30 PM, Roberto Lopez <robe...@gmail.com> wrote:

The only thing that you need is to install an AMP server in the machine where the files are located and make the machine available via Internet, then HMGSCRIPT apps and LAN apps could share the same data.

 

 

Wow ! you like to live dangerously !

 

 Congratulation for the interesting project but web applications are a bit different from standard applications and this difference must be clear to programmers...

[Roberto Lopez]

 

Wow ! you like to live dangerously !

With the required security measures, data sharing can be done safely.

 

 Congratulation for the interesting project

Thanks!

 

but web applications are a bit different from standard applications and this difference must be clear to programmers...

The main goal of the project is exactly the opposite, to make the differences as transparent as possible for programmers. 

Ideally, the HMGSCRIPT programmers will use only one language (JavaScript) and must not to care about asynchronous callbacks. Data is requested to server, the application waits until the response arrives and the program continues. As simple as that.

To make available our Harbour LAN applications on phones and tablets, is not a need for the future, it is required now.

The only thing that all new Internet-connected devices has, is a standards compliant web browser, so, the choice is clear.

Harbour needs to be closer to the web if it is going to survive.

A little of history:

IMHO, Harbour should had an official GUI (a lightweight, simple one). Many years ago, HGF generated high hopes in the community, but it was abandoned. I'm sure that if HGF were continued, Harbour could have today an important role on desktop applications developing.

Now:

I hope that Harbour will not miss the opportunity again. Then years after HGF, Harbour should to officially start supporting web technologies. Someone can claim that there are contributions and independent projects that cares about that, but is not the same thing.

I still having faith :)

Just my opinion.

Regards,

Roberto.

[vszakats]

Hi,

On Sunday, August 5, 2012 3:20:54 PM UTC+2, Roberto Lopez wrote:

I hope that Harbour will not miss the opportunity again. Then years after HGF, Harbour should to officially start supporting web technologies. Someone can claim that there are contributions and independent projects that cares about that, but is not the same thing.

I still having faith :)

Can you describe what do you expect from Harbour "official" 

decision makers in order to make this happen?

BTW 1, never heard of HGF. Does it have a website or online 

archive somewhere? Why did they stop?

BTW 2, what do mean by "supporting web technologies"? There 

are many of those, I wonder which ones do you have in mind.

-- Viktor

[Roberto Lopez]

On Sunday, August 5, 2012 1:46:31 PM UTC-3, vszakats wrote:

Can you describe what do you expect from Harbour "official" 

decision makers in order to make this happen?

Realize the need to give to Harbour the ability to be a 'full solution' to develop web applications. To drive xBase to the web.

I mean: Clipper was at its time, a full solution for developers. A Clipper compiler could solve all your development needs. That was one of the main keys for its success.

Harbour should become a tool that give to the developers a full solution to create a web app.

There are independent efforts on such direction, but if Harbour main developers establish the guidelines, involves themselves and focus community energy on a unique goal, the things could be very different.

BTW 1, never heard of HGF. Does it have a website or online 

archive somewhere? Why did they stop?

HGF (Harbour GUI Framework) was a project lead by Antonio Linares and Alexander Kresin about ten years ago. The goal of the project was to create a multi-platform GUI for Harbour. 

It grown very fast and had basic support for Windows, Linux and OS/2 (still relevant at that time).

The goal was to have the same syntax (classes) at user level for all platforms. The problems appeared regarding how lower levels should be coded, then the project was abandoned. 

IMHO, if (at that time) HGF were finished, the position of Harbour on the desktop development tools world could be very different.

You surely will find more info about it, reading mailing list archives about 2001-2002. I don't know if any copy of the code remains.

 

BTW 2, what do mean by "supporting web technologies"? There 

are many of those, I wonder which ones do you have in mind.

We should be able to make Harbour apps (I mean, at least console ones) to run using a web browser as interface with remote data keeping the user app source code (nearly) unchanged.

HTML5/DOM/JavaScript combination is extremely powerful. The standard 5.3 GUI classes format (Get, Checkbox, PushButton, RadioButton, etc) could be used to create new JavaScript classes that emulate the Clipper ones.

The application could run entirely on server, sending HTML+JavaScript to the client, or compiled to JavaScript to run mainly on client.

The communication between client and server could be done via websockets, or xmlhttprequest (preferably synchronous to emulate better Clipper experience).

There are a lot of possibilities, but IMHO, the important thing, is that from a Harbour programmer POV, only one tool be required to create a web app: Harbour.

IMHO, that will keep Harbour alive. We could have only one tool, to be on phones, tablets, TV's and even PC's, without regarding which operating system they uses.

I know, that is an enormous work, requiring many talented programmers working together for many, many time (maybe years), I was only expressing a wish.

Regards,

Roberto.

[Roberto Lopez]

On Sunday, August 5, 2012 1:46:31 PM UTC-3, vszakats wrote:

BTW 2, what do mean by "supporting web technologies"? There 

are many of those, I wonder which ones do you have in mind.

Talking about wishes and if it were my call, Harbour compiler should be able to alternatively generate a JavaScript output.

Then, the application could run entirely on client web browser, excepting, of course, for required support for remote data on servers (modern browsers allows you to handle local data too).

As you surely know, Google applications works that way (Java compiled to JavaScript).

There is an interesting product called NS BASIC (http://www.nsbasic.com/) that translates a Visual basic subset to JavaScript to be executed in web browsers.

Harbour could do the same thing for Clipper.

Please note that newer versions of browsers executes JavaScript extremely fast, so, speed is not a problem anymore.

Regards,

Roberto.

[Mario H. Sabado]

Hi Roberto,

Could be similar to CoffeScript?

http://jashkenas.github.com/coffee-script/

Regards,
Mario

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

[Reinaldo]

Roberto -and everyone else;

Access to .dbfs/cdx and .dbf/ntx using PHP has existed for the longest time.  Have your .dbfs on a directory or as part of a Data Dictionary on a server running the ADS server service.  Then have the same server or another server running IIS or Apache with PHP.  Write your web portal using PHP + the ADS php language extension.  You will have access to your .dbfs just as if they were mysql tables.

BTW - The same can be done with .Net, DBI/Perl, Java, MDAC, OLE DB, ADO, Visual Basic, Delphi, C++... and not just PHP and Harbour.  AMOF, you could just as well distribute the very same win32 app you are using on the lan to remote customers and have them connect to your .dbfs via the Internet.

I have many harbour apps writing/reading dbf data on a LAN and a few others reading/writing data to the very same .dbfs over the Internet using PHP.  Simple, fast.  Lacks nothing.

Thought you'd like to know.

Reinaldo.

Unsubscribe: harbour-users+unsubscribe@googlegroups.com
Web: http://groups.google.com/group/harbour-users

[Roberto Lopez]

On Sunday, August 5, 2012 8:27:24 PM UTC-3, mhsabado wrote:

Hi Roberto,

Could be similar to CoffeScript?

http://jashkenas.github.com/coffee-script/

I don't know that product. I'll take a look at it.

Regards,

Roberto.

[Roberto Lopez]

On Sunday, August 5, 2012 8:54:48 PM UTC-3, Reinaldo wrote:

Roberto -and everyone else;

  AMOF, you could just as well distribute the very same win32 app you are using on the lan to remote customers and have them connect to your .dbfs via the Internet.

I do that for various of my developments, using NETIO and SQLMIX.

It works fantastic. It is fast and reliable and I very happy with that.

The problem arises when users in the same office acquires iPads, Android or Balckberry  tablets.  

Having to re-crerate the original application for each platform has no sense for me, considering that all of them has a common playground: The web browser.

I understand that the JavaScript solution could be considered very ambitious, but as I've mentioned in a previous message, there is a lot of other possible ones.

Regards,

Roberto.

[Reinaldo]

Roberto;

I'm not sure we talking abut the same thing, so just in case, let me also share that with ADS on the server, your win32 apps continue to use sql + ISAM RDD included on harbour,  Android, iPhone, etc.. can also share the same .dbf data via web services.  PHP, JAVA, PERL and the rest have a client to connect to ADS data, so all these methods to read/write .dbfs can be used at the same time.  You probably already know that being that Sybase has made a lot fuss about it and have even created a few web presentations about it.

Having said that, I think you are talking about development language itself.  And yes, you are right, it is a royal pain having to write totally different code for each device.  That will have to, somehow, change at some point; won't it?

Reinaldo.

[Roberto Lopez]

On Sunday, August 5, 2012 1:46:31 PM UTC-3, vszakats wrote:

BTW 2, what do mean by "supporting web technologies"? There 

are many of those, I wonder which ones do you have in mind.

Finally, there is a very interesting and quickly feasible alternative to drive Harbour to the web.

It is GTK broadway backend.

It basically allows you to run GTK based applications in an HTML5 enabled web browser.

Since that there are various GTK libraries for Harbour, it is only matter to plug all the things at the required places.

http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/

http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/

It basically works this way:

"Each toplevel window is mapped to a canvas element, and the content in the windows is updated by streaming commands over a multipart/x-mixed-replace XMLHttpRequest that uses gzip Content-Encoding to compress the data. Window data is pushed as region copies (for scrolling) and image diffs. Images are sent as data: uris of uncompressed png data.

Input is gathered via dom events and sent to the server using websockets."

Besides that, this could be an opportunity to Harbour having it's own GUI. 

Web browsers are present in most platforms, so an official GTK based GUI for Harbour, could be available for nearly all platforms that Harbour supports.

As always said, a modest initial goal, such as have a very few classes using 5.3 GUI classes syntax, could be a nice starting point, since it could be possible to have original Clipper syntax apps, creating true GUI elements in many platforms (including web browsers).

I'm not a GTK specialist, so, I could be missing something, but I'm sure that the project is highly feasible.

Regards,

Roberto.

[Roberto Lopez]

On Monday, August 6, 2012 11:16:23 AM UTC-3, Reinaldo wrote:

Having said that, I think you are talking about development language itself.  And yes, you are right, it is a royal pain having to write totally different code for each device.  That will have to, somehow, change at some point; won't it?

Is a true pain to have to take care about any new OS out here (IOS, Android, BB and soon Firefox OS) and think about how to interface with our Harbour remote data from them. That is what I'm talking about.

Regards,

Roberto.

[Luigi Grella]

Have you looked at Talend?

http://www.talend.com/download_form.php?cont=esb&lang=en&utm_source=google&utm_medium=cpc&utm_campaign=TLD:Brand%20Search:NA&src=GoogleAdwordsOD_US&kid=null&utm_term=talend%20open%20studio&utm_content=General%20Brand

[marek.h...@interia.pl]

"Roberto Lopez" <robe...@gmail.com> pisze:

Hi All,

I'm posting this here, because could be of interest for Harbour users.

[...]

Operations that set or get the field content handles all  original  dbf data types (character, numeric, logical and date) as strings (See the sample code for more info).

You can download at: http://sourceforge.net/projects/hmgscript/

Hi,

Why do not you put this in harbour\contrib ?

Regards,
Marek Horodyski

[Roberto Lopez]

Luigi Grella wrote:

Have you looked at Talend?

[Roberto Lopez]

homar wrote:

Why do not you put this in harbour\contrib ?

The only Harbour-related thing in HMGSCRIPT is its capability to handle dbf files.

So, it is not really related to Harbour compiler itself.

Regards,

Roberto.