Is PHP a good choice for Desktop Apps?

Anon

Hi guys:
I need to build an application for my company, It will be an administrative and accounting application.
I want to make it available as an intranet and extranet.

The real core will be a MySQL database, I want to build the main application in PHP, the same for the intranet Desktops and the extranet clients.

I have read that a Web-based application is not good for a Desktop. is this correct?

Should I build just the PHP app.
or
Java or C++ clients for desktops and PHP for extranet ??

Thanks,
Miguel

Anon

What do you mean with 'not good for a desktop'?

We builded in the last year a wholesale application with stock, billing, ordering aso.
We use MySQL, PHP4 and a little bit of javascript.

We did it in a quarter of the time we would need with a client/server application.

There are no problems about software distribution and we have everything under control.

Problems are all reproducable, not like in a windos c/s application.

No problems to change the server, the database to an other server, one point of control.

We create all our customer documents on the server with xml/xslt, convert it with fop to pdf and print direkt from the server to the specific printer.

It was an easy way to create a full featured application.

For a system like that I would take the same choice.

We will develop a B2B appication starting in the next half year. We discuss to realize the frontend in the internet with zope. (where also some php4 can be (re) used). But the B2C application has very different goals then our inhous application.

[deleted]

PHP was designed to be used over the web.
If you don't need the web interface part, then don't use PHP.

If you want a real client-server app with full funcionality, then use something like C++ or Delphi. PHP is specifically for WEB applications, which means that you have zero control over the clients, they are stateless.

You can't keep database transactions open between user-operations, you cannot reliably lock records, basically you can't do any of the things that an accounting application would need.

PHP is great, superfast, and you can build just about anything in very little time, but it has it's limits.

Just think about the sh*tload of problems you'll get with users pressing reload all the time...

[deleted]

"We did it in a quarter of the time we would need with a client/server application."

That depends 100% on how competent you are with 'the other language'.

That's no argument for or against PHP.

What does count against PHP is that it requires a webbrowser, whichs means you get a stateless interface, which is a no-no for a serious application, especially accounting.

Anon

What vincent point about the "reloads" is my main fear. How did you solved this problem??
Im planning on making a log for each session and do not allow the same action two repeated times... but do not know yet.

Anon

Whow!!!

This is not so simple.

To create transactional like application like you do with php is much more easier and faster do design and realize than a c/s application with an event handler.

In php you have an input to a program and a output, no events from user by clicking with his mouse and so on.

It depends a lot about the environment you use and how your design has to show on these.

In our project we were all beginners with php but we had a lot of expirience in other languages like C, PL1, Pascal in C/S environment (We 3 together more than 25 years).
Realize the same application with the same functionality whith the same user wishes would really used much more time.

Charley

Anon

i agree with what you say vincent but what about php-gtk?

Anon

We hvae no problems about that reload. I think there are two reasons:

Because it is a intranet application, we use a frameset. If the user presses the reload button, he will have the standard page on the table. If he really want to do a reload, he has to use the context menu with the right mouse button.
Normally the reaction of the program is so fast, that no user want to refresh. (We have a intranet with 100MBit and a fast, dedicated Linux box for the server)
We had troubles there with printing documents, so we put the document print into the background. For every physicle document to print we queue it in a directory and a batch process will take it and print it. In that way we come back to a short response time.

Charley

[deleted]

PHP-GTK nice/cool, but that's really just re-inventing the wheel.
Simply put: PHP+GTK=Delphi.

Besides, PHP+gtk is hardly a proven technology 🙂

That's another thing you need for a 'proper' application: reproducable technology.
If you had built your app in PHP3, it would seriously fail in PHP4, and even worse in php 4.1 (just thing of $_GET etc)

PHP is undergoing too many changes, it's maturing rapidly, which does make it a candidate in future, but right now it's not 'stable' enough for business-critical applications, too many functions are changing, too many new functions are added.

That's ok for a website, PHP has more than proven it's worth there.
But your website does not do your accounting. If your website stops, you may loose customers/orders, but if your internal administration backfires, you go belly-up.

[deleted]

So he can still reload, you just made it more difficult to do? Did you do anything to make sure that nothing goes wrong if someone does reload? (no offence, just curious)
Users are inherently stupid; they will reload even if they don't have to. 🙂

My point is that if something can get you into trouble, then that something should be made impossible, and that's very difficult through a web interface, and easy-peasy using a 'real' language.

Anon

The only problem I have with reload is when the user reloads a page which is still in progress.
There i have to look that the response time is so fast that this should not happen.

That's why we put time consuming tasks in a background process... to have good response time.

If the user do a reload or an other user do a mutation on the same record, this problem is the same.

We have a mutation timestamp in every table and when we read, we read that timestamp and save it in the session, when we update we control the timestamp and if it is not the same we tell the user that someone other did a change of the data and don't update.
The same would happen, if a user push the reload button after he gave the command for a update.

[deleted]

Do you use SQL transactions?

Anon

Yes, we do. If you want to be shure that your relations are ok and your data is consistent, you should use it.