Re: Web application: Programming language/Framework - Mailing list pgsql-general

From Joshua D. Drake
Subject Re: Web application: Programming language/Framework
Date
Msg-id 411E53BC.2010605@commandprompt.com
Whole thread Raw
In response to Re: Web application: Programming language/Framework  (Chris Travers <chris@travelamericas.com>)
Responses Re: Web application: Programming language/Framework
List pgsql-general
Chris Travers wrote:

> Hi Arthur;
>
> Ah, the topic of flame wars.
>
My company also does a great deal of web application programming. Rule
of thumb for us is:

Anything system/administrative level  goes in Perl.
Anything application/oo or server level (triggeres for example, or
processes) go in Python
Anything Web goes in PHP (Although we are rethinking that do to the
constant OO issues with PHP).

Sincerely,

Joshua D. Drake





> I program in Perl, Python, and PHP.  I use them for different
> applications, but they are all good.  Usually I use PHP for web apps,
> Perl and Python for other apps.  But these are not hard and fast rules.
>
> Best Wishes,
> Chris Travers
> Metatron Technology Consulting
>
> ps Additional comments inline.
>
> Arthur van Dorp wrote:
>
>> Hi all
>>
>> This is a bit off topic but I don't know where else to ask (please tell
>> me if you know). I'm going to build a web application. The choice of the
>> underlying database wasn't difficult. After a few preliminary tests I'm
>> confident that PostgreSQL is absolutely up to the task. But I'm at a
>> loss regarding the "middleware". I know Apache quite well, so I wouldn't
>> mind continuing using it. But what language/application server/whatever
>> do you recommend? Java/J2EE/JBoss, Struts, Perl, Python/Zope, PHP 5,
>> XYZ...? There are a few prerequisits such a framework would have to
>> meet:
>>
>> * Reasonably scalable.
>> * Works well together with PostgreSQL. An abstraction layer which
>> separates the SQL stuff from the rest probably wouldn't be bad either.
>> * Security:
>>     * I don't like to worry to much about buffer overflows, SQL
>>     injections and the like when coding.
>
>
> Buffer overruns are prevented in Perl, Python, and PHP.  SQL injection
> attacks are a much larger issue though.
>
>>     * The framework shouldn't need a security update every few days.
>>     * Support for encryption at the web frontend side and possibly
>>     on the DB end (OpenSSL being my favorite).
>> * Well established: Nothing that vanishes after a few months just
>> because it was the latest craze. Something where you find documentation,
>> mailing lists and a community.
>> * Free (open source) and free (or reasonably priced with the possibility
>> to change the provider). I've had my share of vendor lock-in.
>> * Support for handling XML data as in- and output.
>> * Separation of web frontend logic and web frontend design.
>> * Ease of use is never bad. ;)
>
>
>
> Otherwise, I like PHP, Perl, and Python.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faqs/FAQ.html



--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


pgsql-general by date:

Previous
From: CSN
Date:
Subject: idle processes
Next
From: Robert Paulsen
Date:
Subject: Re: idle processes