Re: Why PHP?

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

Regards
Simon
"Tom deL" <ted@xxxxxxxxxxxxxx> wrote in message
news:1131675461.470553.148630@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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
>


.

Relevant Pages

  • Re: Breaking backwards compatibility - good or bad?
    ... coming and are needed to anything really big and useful in PHP. ... command or statement in the language that is going to be made invalid ... The PHP team tries very hard not to break CORRECT scripts. ... "Introducing case-sensitivity for variables and functions names has ...
    (comp.lang.php)
  • Re: Case sensitivity in programming languages.
    ... the language. ... And these conventions take advantage of case sensitivity. ... In PHP it can be any of those things. ... group of programmers who want t force their stupid ideas onto others. ...
    (comp.lang.php)
  • Re: A Lot of Questions from a Noob
    ... OOP is a language paradigm that is not specific to ... I Google'd for an introduction to object-oriented programming, ... Watch out for the die-hard Perl fanbois: ... PHP 5 OOP has come a long way from PHP 4. ...
    (comp.lang.php)
  • Re: Wordpress Port
    ... I think Ruby is also generally useful. ... easier to work with than Perl. ... PHP was obviously designed ... primarily as a procedural language, so it's sort of appropriate for ...
    (comp.lang.ruby)
  • Re: Case sensitivity in programming languages.
    ... Is any language issued with a set of function names in different ... You get a warning if you reference an undeclared variable in PHP if your ... In something like PHP we could generate a convention ... The ability to have 3 different functions called readfile(), ...
    (comp.lang.php)