Re: php form and ssi

Henrik Carlqvist wrote:
Jerry Stuckle <jstucklex@xxxxxxxxxxxxx> wrote:
How many sites can you point me to which are using no high level languages? How successful are they?

Of course all bigger sites are using some kind of high level langauge. By
definition any site using phpoi will also be using php. However, there are
many different ways to build sites. As I asked my question in this group I
should expect to get php-centric answers but nevertheless I would find it
nice if phpoi were easily usable also by sites not built from the
beginning with php. SSI is one such simple technology that can be used
to let static .shtml files call dynamic contents from php, perl or
whatever language of your choice.


Any site which handles POST or GET requests is using a web language.

But you just can't understand, can you. SSI is inherently incompatible with web languages. It is only used for static pages.

The two current sites both existed long before phpoi existed and they
were built using the current technology with SSI.

And they use NO high level languages? Must not be very successful.

One of the sites did not use any high level languages before. The other
site were already using php and a database backend for other dynamic
contents.

So they were a completely static site. No problem. They can still use dynamic pages. Just not with SSI.

Why would any site need to use IIS, anyway?

There are a huge number of reasons why they use IIS.

Pardon me for being a bit provocative about IIS. I really would like phpoi
to work fine with IIS. However I do find your assumption that any site
built upon SSI easily can be reencoded a little bit unrealistic. By
putting SSI and IIS agains each other I was hoping to be enough pedagogic
even to an IIS fan to point out that existing sites does not want to
change their current infrastructure to get a new functionality. It seems
that I failed to get my point through.


Over 15 years of web coding has shown different. There is very little difference between a page coded in SSI and one coded in PHP but not using other PHP features. But you fail to understand that.

But if you care su much for IIS and don't care at all about SSI, what
about the following solution:

It's very easy. Code the entire page as a PHP page - as people have
told you. Don't even use SSI. It works fine.

I don't want to put this requirement on every user of phpoi. I would
prefer a solution that works fine together with other technologies than
php.

Then be forever relegated to your two users. You won't find many takers with that attitude.

I have no IIS server to test this on so I can't say for sure that it
works, but the intention is to at least be backwords compatible with
IIS even though IIS users will lose the SSI functionality. I would
really prefer a solution where SSI also worked with IIS though.

When releasing an open source product, you should be testing on all
major platforms.

You should not expect open source projects to be tested on proprieatary
and costly platforms. Why should I spend money on yet another operating
system only to test a program that I am writing for free? If other people
are willing to do the testing on proprietary platforms thats fine with me.
I would be happy to accept contributed bug fixes. However I will not buy
myself a Windows License only to test on a server platform that I normally
don't use myself and only has about 1/3 of the market share.


When you are talking about a platform with a large portion of the market (and like it or not, IIS does command a significant share), then yes, I do.

1/3 of the market share is a HUGE amount of market share.

Gee, maybe you should have them change to Linux/Apache. After all, it
shouldn't require any rewriting of their site.

That would be true in that specific case. However I still don't like
having requirements of changing the current site to be able to use phpoi.

And your attitude will forever relegate you to being a small niche project. Because the vast majority of people who are already using PHP and other high level languages will not use it.

You need PHP on the site, anyway, to use your page. And you'll find
some other technologies (i.e. VBScript) do not integrate well with PHP.
You can do it - but it's not real easy.

There are many ways to build sites. VB, php, flash, perl, ruby and so on.
Most of them has one least common denominator and that is the fact that
they produce html served to the web browser. Another least common
denominator is SSI which mostly is available on the web server. SSI is a
technology that can call dynamic contents from many different languages
including php.


Sure, the produce HTML. But no SSI is NOT a common denominator. Pages using web programming languages do not use SSI. But you just can't understand that.

Only put out your part of the info. Leave the rest to the user.

That is exactly what I wan't to do. I do realize that the user easily can
include my scripts from their own php scritps with include(), but I also
want users who hasn't built their sites with php to be able to call my
scripts.


They can do that anyway. But not with SSI - it is inherently incompatible with web programming languages.

Then don't worry about .shtml and don't use virtual(). Use what
everyone else uses.

Sorry, to sacrifice all my current users because "everyone else is
using php on IIS" does not sound like a real world solution to me.

No problem. You'll just ignore the rest of the world instead, for your
two customers.

But the solution last mentioned was supposed to work also with IIS. It
would only not be possible to use SSI on IIS. As SSI is no concern of
yours I thought you would be happy with that solution?


It is possible to use SSI on IIS. But you just can't get it through your head that SSI and high level languages are inherently incompatible.

Sure, there are things you can do to MAKE them work - at a huge performance penalty to the server.

What you need to do is concentrate on outputting your data, and don't
format anything outside of your stuff. Then make it easy for the client
to include in their pages.

That is exactly what I am trying to do.

regards Henrik

Then forget about your preconceived ideas and listen.

But all you want to do is argue. And I'm through arguing with you.

Have fun with your "project". It will never go anywhere until you learn how to do open source *properly*. But by then someone else will have done the same thing the right way, so no problem.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: php form and ssi
    ... definition any site using phpoi will also be using php. ... SSI is one such simple technology that can be used ... One of the sites did not use any high level languages before. ... Pardon me for being a bit provocative about IIS. ...
    (comp.lang.php)
  • Re: php form and ssi
    ... web languages including php. ... you by "inherently" mean that SSI is unable to pass POST variables? ...
    (comp.lang.php)
  • Re: php form and ssi
    ... web languages including php. ... Just not with SSI. ...
    (comp.lang.php)
  • Re: php form and ssi
    ... Of course no site "needs" to use SSI. ... reencoding and would in most cases be even easier than reencoding the ... site from SSI to php. ... There are a huge number of reasons why they use IIS. ...
    (comp.lang.php)
  • Re: php form and ssi
    ... to use SSI, anyway? ... Why would any site need to use IIS, ... reencoding and would in most cases be even easier than reencoding the ... site from SSI to php. ...
    (comp.lang.php)