Why PHP?

#31

Hi Tony,

Quote:

So far the points regarding PHP vs Perl don't seem to make that much
distinction, so at the moment I'm not being compelled toward PHP

If one is comfortable with one's confort level with any language that
gets the job done, there should be no compulsion IMHO. As I have
mentioned several times here, the things that compell me are often
simply how much time I spend muttering 'I wish ...'

Quote:

_from_ Perl. For example, Perl can maintain multiple simultaneous
connections to databases, it's OO, a .pl file is as capable of
generating HTML as a .php file, it's also good for shell scripting
which is completely unrelated to HTML, etc. However, the similarities
and some of my recent client efforts do compel me to spend more time
with PHP than I used to - it's only fair seeing that PHP (now) does
have the same capabilities, and may be more elegant besides.

Your mentioning OO makes me think that I should say that I use PHP
almost exclusively as a procedural language, using objects mainly as
convenient storage and transmission devices.

It would be my hope that the fact that all of my words here are based
upon how _I_ use it does not obscure the fact that PHP can be used as
an OO tool as well. In fact in PHP5 a great amount of effort was placed
into firming up the PHP object model.

Another thought: When Googling 'PHP vs. Perl' aside from the usual
religious arguments, an awful lot of dated information and
misinformation surfaced in the very first hits. So please don't take
things that you read on peoples' sites and blogs as gospel (TM).

In particular I saw many references to PHP as an SSI device only,
perhaps adding to the 'PHP must mix HTML and processing' impression
that I see here. More often than not PHP is used in the same way as is
Perl or Java - as an application rather than as scattered SSI includes
in an HTML document.

In the W-Agora project - http://www.w-agora.net/ we were using the
'central application' approach before the turn of the Century.
-Tom

#32

I guess when I said "tastes", there was an implied suggestion that the tool
chosen to do the job could actually do it! If one of the requirements was
that it had to run on a public ISP/Hosting server then a prerequisite would
have to be the availability of the chosen tool!!

But yes - agreed - availability is important...

Regards
Simon

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Quote:

Simon Verona wrote:
Just to pick up on a minor throwaway point you make.

Reusing legacy code in a web application can be a major decision maker
when
choosing a technology. I've had a very similar issue when porting our
character app to a windows thick-client. By being able to make use of
well
written business logic reduces development time in porting a legacy
pplication significantly.

As far as using PHP - which is the topic goes - I guess it's just another
tool that can do the job. Whether it does the job *better* than any
other
tool is really down to individual tastes.

If it were just about tastes, you wouldn't find me deciding to jump in.
However, it is also about availability. Most ISP's provide PHP (along
with html, css, and javascript). My tastes would have me do Java,
Ruby, Python, PHP, then Perl and yet I'm gonna try my hand at PHP.

There are various
alternatives - some proprietary to the Multi-value marketplace, some more
mainstream - but I've tended to always pick my tools based on the ones
that
I can most easily learn which do the job.

For me, this has been .net. Being tied to Windows isn't really an issue
for me (which is the main bugbear with .net I believe). It also gives me
a
common development language and methodology for web and thick clients
which
reduces the number of development languages and libaries I need to learn!

Just my two cents worth..

I think MS has done a wonderful job with tools and development
environments for s/w developers. While there are non-MS technologies
that rival MS's, there is nothing open source that rivals MS for
developer tools as far as I've seen. --dawn

Regards
Simon
"Tom deL" <ted (AT) blackflute (DOT) com> wrote in message
news:1131675461.470553.148630 (AT) g49g2000cwa (DOT) googlegroups.com...
Hi Mike,

I too like MV/BASIC but in spite of my
preaching against this, in the web context I mostly use openQM as a
backend and use PHP instead of MV/BASIC for the bulk of the work.

That's what I'm curious about. Would you really (ideally) use PHP to
tell Pick/OpenQM what to do on one side and the client what to do on
the other - rather than dispense with the "middle-man" and cut to the
chase. I mean - it seems you're passing instructions to Pick which
have
to be interpreted once they get there in order to be carried out. Why
bother - if that's all you're doing? Wouldn't it be
better/simpler/more
efficient do it all in Pick (or OpenQM) instead - if you could?

Well ... I am thinking about this. One thing that I should point out
however is that using the client library and PHP things are not being
'interpreted once they get there' - most of the calls are C language
routines that (the object code for) were loaded when Apache started. So
the QMField(), etc. is happening very quickly and efficiently inside a
well controlled, multi threaded daemon (Apache). The only things that
even touch the server are things like OPEN, READ, WRITE, SORT, LIST.

And remember that I started this with 'maybe I am biased toward
something to which I have become accustomed'. All in all it (the way I
am doing it) is pretty efficient and proven. Does it justify someone
from the PICK world learning a new language? Maybe not.

In another conversation (too many going on right now), I have been
discussing using a bash script as a cgi program, calling the qm binary
with an argument. This is cumbersome, probably too slow and certainly
difficult to secure but ... in this discussion Martin mentioned a C
language cgi interface. I am looking at that and thinking that there is
a real possibility for a simple interface that will allow (almost)
everything to be done in BASIC. This is something that I hope to have
the time to explore over the weekend.

So, perhaps Monday I will answer your question with 'Yes, that was a
great idea to get rid of the middle additional language.' We will see.
As Glen pointed out however, PHP has support for many modern approaches
and concepts that may take enormous amounts work to implement in BASIC.

Wouldn't it also then be a whole lot easier to re-use more of your
legacy green-screen code?

Yikes!!! I don't know if that would be such a good idea. LOL

As I have mentioned elsewhere, PHP has very well evolved database
--
web features. It makes a great 'glue' with which to predictably and
securely tie the two together. There are 'simpler' ways (cgi, direct
connection, etc.) but for creating anything approaching an
application,
the tools are all there and well tested in PHP.

Ouch! I really don't like that "anything approaching an application"
s**t. I'd love to be able to direct you to the Hill House Hammond site
where you could run a Pick application to take you through the process
of buying a motor or household insurance policy online - but HHH is no
more (the parent company closed their subsidiary down as part of a
consolidation thing). There were other browser-based apps for in-house
use there too that were full-blown applications just like any of the
green-screen apps. My framework - which *will* see the light of day
eventually - is way more advanced again than any of those, and will
allow much more sophisticated applications to be built too. I say all
this because I felt I was being talked down to - and that p****s me

That was not the way it was intended. I have big feet, sorry that I
don't always make the time to watch for others' toes.

off. When everyone else was going on about how difficult it was to
write "proper" applications for browsers years ago, and the difficulty
with maintaining state, and what to do about read-locks, and how to
authorise credit card payments, and how to send and refresh individual
fields, and how to navigate using images, and how to cater for use of
the broswer's Back and Fwd buttons, etc., etc., these things were
quickly and simply dealt with - largely because they were being
controlled from within Pick using PickBasic with nothing but the
FlashCONNECT agent running on the web-server.

As was I but not with PICKlikes. And in all of this I have been
thinking in terms of things that can be handed to fairly normal
programmers without undue amounts of 'gotcha' if they forget a hidden
field or whatever. All of those simplicity vs. flexibility issues.

On to some of your specifics:

[snipped a lot of potentially interesting stuff about how to mimic
PickBasic using PHP]

OK, now that I have gone on about my choice ... you might want to
keep
an eye on openQM. It is beginning to appear that Martin might have
one
of his solid, simple, useful tricks up his sleeve.

Tantalising. I'll keep a watch and I'll keep waiting (a line from...
oh... some song by John Martyn).

Maybe after the weekend there will be news. Or maybe I will drink a lot
of beer and get the boat ready for Winter.
-Tom

#33

Tom deL wrote:
[snip]

Quote:

In particular I saw many references to PHP as an SSI device only,
perhaps adding to the 'PHP must mix HTML and processing' impression
that I see here. More often than not PHP is used in the same way as is
Perl or Java - as an application rather than as scattered SSI includes
in an HTML document.

Interesting. I'd only seen it as Server-Side Includes,
which left me cold. Think I'll take another look at
PHP now, as the hosting company for my personal website
supports it, and I've wanted to create DHTML there.

--
frosty

#34

frosty wrote:

Quote:

Tom deL wrote:
[snip]
In particular I saw many references to PHP as an SSI device only,
perhaps adding to the 'PHP must mix HTML and processing' impression
that I see here. More often than not PHP is used in the same way as is
Perl or Java - as an application rather than as scattered SSI includes
in an HTML document.

Interesting. I'd only seen it as Server-Side Includes,
which left me cold.

Me too, but with the approach of passing XHTML with JavaScript that
uses server-side services (often asynch), those services can be written
in PHP.

Quote:

Think I'll take another look at
PHP now, as the hosting company for my personal website
supports it, and I've wanted to create DHTML there.

That's why I'm getting started with it. Enjoy! --dawn

Quote:

--
frosty

#35

Hi Dawn and Frosty,

Quote:

Interesting. I'd only seen it as Server-Side Includes,
which left me cold.

Me too, but with the approach of passing XHTML with JavaScript that
uses server-side services (often asynch), those services can be written
in PHP.

This implies that one needs javaScript and XHTL in order to use PHP
outside the SSI context and this is simply not true.

Since at least 1997 (PHP 3.0) PHP has had full application
capabilities. There is a huge litany of large applications out there
written entirely on PHP.

To reiterate: PHP is by no means limited to single line SSI.

In fact way back then I moved to PHP from a MVWWW-like SSI system
called 'WWW-SQL' expressly because of the limitations of this
implementation. Development of WWW-SQL was dropped very shortly after
PHP 3.0 was released.

Google around, take a look at sites like http://www.hotscripts.com/ to
see what people are doing with PHP.
-Tom

#36

On 16 Nov 2005 14:08:30 -0800, "Tom deL" <ted (AT) blackflute (DOT) com> wrote:

Quote:

Hi Dawn and Frosty,

Interesting. I'd only seen it as Server-Side Includes,
which left me cold.

Me too, but with the approach of passing XHTML with JavaScript that
uses server-side services (often asynch), those services can be written
in PHP.

This implies that one needs javaScript and XHTL in order to use PHP
outside the SSI context and this is simply not true.

Since at least 1997 (PHP 3.0) PHP has had full application
capabilities. There is a huge litany of large applications out there
written entirely on PHP.

To reiterate: PHP is by no means limited to single line SSI.

In fact way back then I moved to PHP from a MVWWW-like SSI system
called 'WWW-SQL' expressly because of the limitations of this
implementation. Development of WWW-SQL was dropped very shortly after
PHP 3.0 was released.

Actually, MVWWW is an open connectivity framework and has nothing to
with server side includes, Apache, or any one specific technology.
It's similar to FC on the MV side, but that's about all of the
commonalities.

Glen

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

#37

Hi Glen,

<snip>

Quote:

Actually, MVWWW is an open connectivity framework and has nothing to
with server side includes, Apache, or any one specific technology.

Of course, I am sorry - was confusing thoughts of your recent
discussions of how you _use_ MVWWW with the tool itself.
-Tom

#38

Quote:

If we're going to talk about web-services, or interacting with
applications running on other servers, it would be good to also hear
about cURL from someone who has used it a lot.

Mike.

I use cURL under D3/Linux to post and retrieve XML for FedEx and UPS.
I haven't submitted my project for FedEx testing and approval yet, but
I'm hoping to do so as soon as I get enough free time at work to
finish my rate and track API. My UPS tracking stuff works great, using
the XML parser I wrote a few years ago for Ariba. I'm also currently
working with Harvey Software and their CPS package. They are using the
same FedEx DirectShip XML API I've been playing with, but they've just
finished a service pack that allows for full, automated, international
and domestic shipping/customs support. I'm still debugging my D3
integration with it. Since they've already done most of the work in
that area, I don't plan on doing much more with cURL than I already
have for independant tracking and rating. That's not to say that I
won't be using cURL for unseen projects in the future.

If you are interested in integrating a shipping package, you should
check out CPS and the Automator. The pricing, features, and support
rivals most of the other solutions I've reviewed.

Glen

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

#39

I've also used cURL extensively and have it posting transactions to
remote servers from D3 in a high-profile client site. Nothing but
good experiences.

T