linux-l: datenbanken

[Steffen Dettmer]

* Guntram Trebs wrote on Sun, Aug 05, 2001 at 14:31 +0200:
> On Fri, 3 Aug 2001, Steffen Dettmer wrote:
> > * Guntram Trebs wrote on Thu, Aug 02, 2001 at 22:27 +0200:

> Früher gab es solche Bugs, jetzt benutze ich Version 2.2.0rc1, ist
> allerdings noch Beta. In dieser Version sind mir noch keine Bugs
> aufgefallen. 

Na, das heißt ja nu nix, daß Dir in der Beta (!) keine Bugs
aufgefallen sind... Aber das Teil wurde definitiv auf bugtraq
erwähnt, und wer weiß, was da noch schlummert.

> Selbst das exportieren und anschliessende Importieren ganzer
> Datenbanken scheint jetzt zu funktionieren.

Na ja, braucht man aber selten, oder? Ich find das PhpPgAdmin
oder wie das für PG heißt, auch ganz nett - aber eben ein PW vor,
sicher ist sichert.

> > mich. Inzwischen kriege ich immer schwitzige Hände, einen
> > wahnsinnigen Blick und Ohrensausen wenn ich PHP (nein, schon
> > wieder) lese/höre... Und ganz besonders mod_php (fröstel).
> 
> Von mod_php hatte ich nichts gesagt, oder?

Weiß nicht, ist jedenfalls sehr verbreitet, bei SuSE z.B.
Standard-RPM.

> [mod_php-Argumente]
> 
> Bei den wichtigen Seiten läuft php unter eigener UserID.

Wie kann ein WWW-Server das entscheiden? Machst Du mod_php und
standalone-PHP? Dann beschreib das mal bitte, klingt
interessant.

[Lib Kram]
> Kannst Du das bitte noch mal genauer erklären, notfalls per PM?
> (Oder web-adressen posten, wo das Thema behandelt wird)

Wenn libxxx einen Bug hat, und PHP diese benutzt, kannst Du
libxxx nicht entfernen, klar. Zur Laufzeit kann man dann auch
wenig gegen tun. Normalerweise kann man sowas ja über
unix-permissions regeln, wenn ein Perl Modul geladen werden soll,
geht das eben nur, wenn die Rechte stimmen. Bei direkt gelinkten
kann man das PHP ja überhaupt nur starten, wenn alle libs da und
lesbar sind. Dann möchte PHP-1.2.3 unbedingt libxxx-0.96, welche
ganz neu, alpha und buggy ist, na, Pech dann. Vielleicht bekommt
man auch nie raus, welche 0.96 Funktion gebraucht wird :)

> > - die zend_engine ist nicht zuverlässig (ach so, muß da noch
> >   meinen patch/bugreport machen :)) und der code sieht auch nicht
> >   gut aus, nichtmal asserts() usw, kaum Fehlerprüfung, selbst bei
> >   -DDEBUG
> 
> assert-Möglichkeit im Code oder im PHP-Skript?

im zend source code (das ist so ne komerzielle expression engine,
die von PHP benutzt wird) und natürlich im PHP source code, den
ich aber nicht weiter betrachtet habe.

> Im PHP-Skript haette ich eh' meine eigenen asserts.

Ein PHP Script darf nicht abstürzen, egal was Du schreibts. Ein
return einer undefinierten Variable oder Aufruf einer
undefinierten Funktion darf einen Fehler melden und abbrechen,
aber keinen Sprung ins Wilde oder Arbeit mit undefinierten Werten
intern durchführen. Das muß die engine (also zend_sonstwas)
abfangen. Meistens macht sie das ja auch :)

> > - das configure läuft auf ner SuSE nicht ohne patchen durch (und
> >   anhand der Marktanteile ist SuSE nicht exotisch)
> > - ich hatte bisher bei *jedem* PHP update Probleme, weil viele
> >   nicht mehr richtig funktionierte und nix reproduzierbar ist
> 
> Das sind hauptsächlich die Probleme meiner Provider.

Sind aber Indizien von Qualitätsproblemen. Ist doch komisch, bei
einem GNU Tool geht configure unter 10 Unixvarianten und linux
sowieso, und bei PHP nichtmal mit SuSE. Möchte mal wissen, wo dsa
configure funktioniert - und warum man es benutzt :)

> > So, jetzt Deine Argumente.
> 
> perl ist viel mächtiger als PHP und ich würde nie auf die Idee kommen,
> riesige Programme in PHP zu schreiben.

:) Ja, bloß manchmal wächst sowas :)

> Dafür ist PHP direkt auf Web-Scripting angelegt und es sind einige
> nützliche Routinen direkt in PHP reincompiliert, die Du bei perl nur als
> zusätzliches Modul mitkriegst.

Na ja, das halte ich eher für einen Vorteil.

> Bei PHP kannst Du HTML-Code und PHP-Code mischen. Das soll zwar bei Perl
> auch gehen, hatte mein Provider damals aber nicht unterstützt.

Na klar geht das auf mehreren Wegen, aber das möchte man nicht.
Entweder Templates oder eben prints. Je nachdem, wie die Seite
aussieht. Ich verwende meist Templates, und baue da einfach
eindeutige Platzhalter ("$datum$") ein, die dann ersetzt werden.

> PHP und HTML zu mischen, ist zwar am Anfang ungewöhnlich,
> bringt aber nach einiger Zeit Vorteile, wenn man sich
> drangewöhnt hat.

Ja, Q&D ist kurzfristig billiger als sauber, ein wichtiger
Vorteil - aber kein schöner.

> Beispiel: Du kannst die PHP-Datei an einen Designer
> weitergeben, 

:) Du bist ja ein ganz mutiger :)
Dann guckst Du mit diff oder wdiff nach, ob sich kein Code
geändert hat, oder wie? Ich würde einfach ne Template von
Designer kaufen :)

[PHP/HTML Beispiel]
> OK. Das treibt 'nem Programmierer die Tränen in die Augen.

Du sagst es, da muß man Vertrauen haben :)

Beispiel Template:

<HTML>....
<BODY>....
<H1>Fehler</H1>
$error_mess$<br>
...

Der Designer macht dann 

<H1>
  Fehler
</H1>
<P class="important_message">
  $error_mess$
</P>

daraus. Finde ich viel lesbarer, als wenn da noch PHP code
dazwischen runlungern würde.

Warum nicht einfach print $html_code? Oder echo(?) in PHP, egal,
also:

print "<H1>Title</H1>\n"; 
oder sowas. Da kann man schön Variablen einbauen und so. 

Aber richtig CooL ist, wenn man Templates verwendet, diese über
WML erzeugt. WML macht z.B. die Erstellung von mehrsprachigen
Dokumenten einfacher, unterstützt bei Tabellen und sonstwas. Wenn
man seine Platzhalter geschickt wählt (also nicht <PLATZ> oder
Sonderzeichen), ist die Template sogar gültiger HTML Code (meist
bis auf wenige Ausnahmen :)), den man mit tidy oder weblint
validieren kann - und zwar gleich im Makefile. HTML ok oder STOP
:)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.