There has been a lot of discussion here lately regarding PHP. I must
admit I am totally ignorant about it. Until now I've never even been
curious about it. I've guessed it was something for those poor
underpriviledged people that have applications outside the DBMS.

The model I like is one with a really thin web-server. All I feel I
need there is the absolute minimum required to securely and efficiently
act as a go-between between clients (browsers) and Pick/MV processes
running PickBasic code on the database/application server. All I want
to store on the web-server are binary images etc. that the web-server
can send to the client as required along with the data being sent out
the door from the database/application server.

What can PHP do that I can't more easily and efficiently do in
PickBasic on the database/application server?

Mike.

michael (AT) preece (DOT) net wrote:
PHP is now a part of the Apache web server, that has some huge part of
the web server market. So, ISPs and others often have it available.

Interest a 22-year old CS major? Also, I can't write something in
DataBASIC for U2 that gets executed after I type in a URL (or access
one). You can write PHP code that is executed with POSTs or GETs from
html/javascript. I'm sure there are other good reasons, but I only
know why I have wandered into it and about to write code in a language
that puts dollar signs in front of variable names after avoiding Perl
for all these years. --dawn

michael (AT) preece (DOT) net wrote:
PHP is now a part of the Apache web server, that has some huge part of
the web server market. So, ISPs and others often have it available.

Interest a 22-year old CS major? Also, I can't write something in
DataBASIC for U2 that gets executed after I type in a URL (or access
one). You can write PHP code that is executed with POSTs or GETs from
html/javascript. I'm sure there are other good reasons, but I only
know why I have wandered into it and about to write code in a language
that puts dollar signs in front of variable names after avoiding Perl
for all these years. --dawn

dawn wrote:

Point!

You'd probably like FlashCONNECT then.

Well - given that the code that gets executed from a POST or GET is a
PickBasic subroutine, in my case - I'd be interested to know more about
those "other good reasons".

Unless/until FC is available on UV it might interest you to look at
Coyote - if you'd like to run things directly from DataBasic inside UV.
Alternatively, can you use PHP to simply "hand-ball" things on to a
waiting process on UV? I guess what I'm asking is : how much does PHP
help and how much would I find it getting in the way?


Cheers
Mike.

dawn wrote:

The Apache you are referring to is the Apache Software Foundation(ASF),
of which the HTTP Server is one of their many projects.

PHP is not part of the Apache HTTP Server project, not one of its
subprojects, nor is it even part of the ASF.

On the ASF website (apache.org) you will find a link to the
organization responsible for PHP (php.net), but that's about it. And
on the PHP website you'll find a link to the ASF - That's about it
there too.

Just wanted to clear that up.

--
Kevin Powick

On 9 Nov 2005 17:12:15 -0800, michael (AT) preece (DOT) net wrote:


FlashCONNECT != PHP

Try parsing and building an XML document natively in FC. Also, PHP is
a server module that runs in parallel with Apache. There is no need
for a DB, unless you want to read/write data from one. SQL support is
native.

True, if you have framework in place to handle HTTP requests.

I guess I really need to get working on MVWWW v2.0.

Using PHP with calls to MV allows you to do a lot of external stuff
without having to monkey with MV. You can easily handle XML services
without having to code any XML stuff in dataBASIC.

Basically, it comes down to application design. If you don't like
any other language except dataBASIC, then your options are quite
limited but you can achieve web intergration. If you're open to using
multiple technologies in combination with MV, then you have a huge
playing field.

Glen

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

Hi Glen,

It has been a long day so this will be mercifully brief, will attempt
to add something tomorrow.

<snip>

Thanks for pointing that out. Session management is another big reason
IMHO and where most other 'solutions' seem quite lacking. And I do need
to look at Coyote soon.

Support for several SQL DBMS's is available if the module is loaded or
compiled in. Support for Bezerkley DB is available. Read only support
for filePro has been available for several years. There is now support
for one MV DBMS - openQM - that is as 'native' as is the support for
any of the other database systems, SQL or otherwise.

And PHP provides a very predictable framework for some of us.

Very true.

Kevin Powick wrote:
I was wrong then. I read that recently and had no reason to doubt it
at the time. I suspect that the person meant that php and apache were
both installed with a LAMP installation then. There might be other
oft-used installation tools that permit you to select PHP with the
apache installation. Or maybe not. I withdraw the statement.

Thanks. It was November already, so I knew I was going to have to be
wrong once before year's end. cheers! --dawn

Glen wrote:

OK. You know where I'm coming from. I guess if I was faced with having
to send/receive XML I might have more of an idea. As you know, with FC
all I get is an array of name/value pairs - along with the HTTP
environment variables, and all I send is javascript functions and HTML.
I haven't made the mind-shift yet from feeling comfortable about doing
everything I need to in PickBasic on the database/application server,
and DHTML on the browser, to whatever else it is I'm missing out on.
Can you provide a simple example to illustrate what it is?

Don't get me wrong here. I *do* like PickBasic. As I've said before -
there is simply *no* better language to use in/with a Pick DBMS.
Outside of Pick of course, PickBasic is nothing at all. Also, if I'm
faced with having to manipulate text strings anywhere on the server
side I feel most comfortable about doing that in PickBasic - regardless
of whether I'm interacting with the database. I also like the fact that
I can easily jump out of Pick down to the host OS to do things (like
Unix !sorts) and back. As an aside - I do wish the non-Pick world was
better at handling delimited text strings. Imagine if Pick-like data,
with char(254)... char(253)... etc. delimiters except with nesting way
beyond the subvalue level, was the accepted way to represent nested
data - rather than XML. Wouldn't that be a hoot?! Talk about the ball
being on the other foot! It'd be our ball park and we'd win every game!

I'm OK with JavaScript for manipulating the DOM and stuff on the client
side. I also like the fact that there is a huge amount of (free) tried
and tested js functions out there if I need to google for it. That said
- I don't love the client-side environment - there seem to be an awful
lot of gotchas to look out for - but, as someone else said recently, I
don't own the horse, I just gotta ride it.

PHP might well be the bees knees for doing things on the middle tier -
the web server. I don't doubt it. I just need to see clearly what it
adds to the mix.

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.

Hi Mike,

Since I am sort of coming back to PICK/MV from many years of PHP/mySQL
I may very well be working from prejudices and preferences. With that
said, having used PHP since its early days, I still find it extremely
useful and easy to work with. Not wrangling with 'I wish it would ...'

Speaking of 'I wish it would' - for all of these years I have found
myself cursing mySQL (mainly the query language) thinking 'I wish I
could make a little DICT item like in PICK and dispense with this
overly complex query'.

So now with the ability to use openQM in place of mySQL I feel that I
have the best of all worlds. 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.

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.

On to some of your specifics:

<snip>

While I don't go to BASIC for this, the qmclientlib contains all of the
FIELD, LOCATE, etc. string handling mechanisms so I can call them
directly from my PHP scripts.

One of the things that I like about PHP is its conceptual similarity to
MV/BASIC. It contains extremely strong array and string handling
mechanisms, is (like MV/BASIC) very weakly typed and is very much at
home with data and database manipulations. Along with this it has the
same kind of shell access so you can access any system command (and
like MV - be careful!).

With PHP I can (and often do) quickly and easily convert a PICK dynamic
array (seen as a delimited string by PHP but as a dynamic array by the
QM_xxx() calls) into PHP arrays and back again.

To make a PHP array of a dynamic array, simply:
$item = explode(AM, $item);

To turn it back into a dynamic array:
$item = implode(AM, $item);

Since PHP array elements can be of any variable type (including arrays)
you can see that this variable nesting is quite easy in PHP. Our
beloved MV is limited to three levels ... PHP isn't so you could build
constructs moving on down the line.

And tons of PHP stuff out there too. Even if just to gawk at for ideas
and solutions ...

That is one of the main reasons that I use PHP as much as possible and
javaScript as little as possible - the paucity of ugly surprises in PHP
<g>

Hope that this helped. Or have I simply become too accustomed to using
it?

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.
-Tom