Mailinglisten-Archive |
* Ralf Geschke wrote:
> Ich frage mal umgekehrt: Was spricht dagegen?
Es existieren bereits die *nativen* PHP4-Sessions.
> Auch Dario wird einen Grund gesehen und daraufhin
> die Initiative ergriffen haben.
Der folgende Ausschnitt aus der Dokumentation läßt mich
daran zweifeln. Falls ich völlig falsch liegen sollte,
möchte ich mich hiermit bei Dario entschuldigen.
| I'm sure there are some good reasons to not use the
| PHP4-internal session-management.
| Don't ask me about them ;-)
(http://php.dn2k.ch/releases/sessionara-1.1_doc.htm)
> Und hast Du Dich nicht kuerzlich in php-dev fuer
> mehrere konkurrierende Datenbank-Abstraktionen
> ausgesprochen, damit eine Wahl derselbe moeglich ist?
Jep, habe ich. Zu beachten ist jedoch, dass wir hier
"native Lösung, die PHP bereits mitbringt" und "selbst
gebastelte Lösung" vergleichen, und nicht wie im Falle von
PEAR::DB "selbst gebastelte Lösung" und "selbst gebastelte
Lösung" (PEAR::DB vs. PHPLIB DB vs. Metabase).
Das, was ich auf PEAR-DEV vermitteln wollte, war im Übrigen
ein anderes Problem, für das ich eine Gefahr sehe: ein
Konsortium von "PEAR-Administratoren" bestimmt, was in PEAR
rein soll und was nicht. Das halte ich für gefährlich, denn
der übliche und evolutionäre Weg sollte sein, dass die
Developer bestimmen, welche PEAR-Klasse am meisten genutzt
wird und welche nicht. Dies ist bei CPAN auch der Fall: es
gibt viele DB-Abstraktionslayer, aber DBI ist wohl der
Quasi-Standard.
> passend. Es gibt Gruende dafuer wie dagegen, entweder
> vorhandene Loesungen anzuwenden oder auf neue zu setzen.
Natürlich. Nur halte ich ein "Ich weiß eigentlich nicht,
warum man die nativen PHP4 Sessions nicht benutzen soll"
für ein mediumgutes Argument. Denn um auf neue Lösungen zu
setzen bedarf es zunächst einer Ist-Analyse (d.h.
vorhandene Lösungen auf den Bedarf hin zu überprüfen). Das
zitierte Argument läßt vermuten, dass nicht wirklich eine
Ist-Analyse durchgeführt wurde. Für den eigenen Lernprozess
kann es aber natürlich auch wichtig sein, selbst Dinge zu
entwickeln, auch wenn es sie bereits gibt. Nur dann sollte
man das bei einer Empfehlung auch dazu sagen.
(Mal davon abgesehen, dass ich es mitunter oft auch für
effektiver halte, sich bestehende Lösungen anzuschauen und
anhand derer, d.h. mit "Use the source, Luke!", zu lernen.)
Was nicht heißen soll, dass ich Darios Leistung schmälern
will, keineswegs (!) und so soll es auch nicht verstanden
werden und er soll jetzt auch nicht vor "Angst" vor mir den
Kopf in den Sand stecken und sich nicht mehr hier
beteiligen.
Nur finde ich, dass es dann eben auch haltbare Argumente
geben soll (im Falle von PEAR::DB dann z.B. ein sehr gutes
OOP-Design), also zum Beispiel "Mich hat es genervt, dass
die nativen PHP4 Sessions jedes Mal ein Cookie setzen
wollen, auch wenn ich Cookies ablehne.[1] Da ich dies
meinen Nutzern nicht zumuten will (weil die Erfahrung
zeigt, dass sie oft Cookies ablehnen), mußte ich das Ding
eben selbst entwickeln, mit allen Nachteilen, die es
aufgrund des jungen Entwicklungsstatus hat. Benutzung auf
eigene Gefahr, hier und da kann es noch haken".
[1]: soweit ich weiß, hatte hartmut das Problem in einer
der früheren PHP4-Versionen gefixt.
[Dario, der nachstehende Text ist *nicht* auf dich gemünzt,
sondern beinhaltet die Allgemeinheit.]
Das Problem des NIH-Syndroms (um mal den Bogen zu einer
allgemeinen Diskussion zu schaffen und in der Hoffnung,
dass Johann sich daran beteiligt ;-) ist meiner Ansicht
nach, dass viele in ihrem stillen Kämmerlein hocken und vor
sich hin entwickeln. Heraus kommt dann das 50.000ste
PHP-basierte "CMS" und wird dann als Revolution gesehen[2],
ohne zu wissen, dass es noch 49.999 andere Leute gibt, die
ein PHP-basiertes "CMS" in der Schublade liegen haben. Ganz
einfach, weil die Leute eins nicht tun: mit anderen
Entwicklern kommunizieren und sich auszutauschen, also
Vitamin B. Mal ganz davon abgesehen, dass viele "CMS"e
eigentlich nur bessere Weblogs sind, denn zu einem CMS
gehört mehr (vgl. Gauss VIP).
Es scheint also mehrere Gruppen zu geben (vgl. OSDN-Studie
über den "Hacker"): die einen (Gruppe 1) wollen lernen oder
haben einfach nur Spaß daran und nehmen es *wissentlich* in
Kauf, dass es die Lösung bereits gibt (sonst hätte ich 1999
nicht http://www.web-cards.de/ entwickelt, ich wollte ein
eCard-System halt auch mal entwickeln, um zu lernen). Und
die andere Gruppe (Gruppe 2) will nicht lernen, sondern ein
Problem lösen, hat aber keinen Kontakt zu anderen
Entwicklern (der eigtl. sehr leicht herstellbar wäre) und
bastelt also still im Kämmerlein vor sich hin und am Ende
kommt dann eine angebliche "Revolution" heraus. Vermutlich
wäre es für Gruppe 2 also günstiger (und hier meine ich
nicht günstiger ausschließlich in Form von Geld) gewesen,
den Kontakt zu anderen zu suchen und/oder zu recherchieren,
ob es denn bereits ähnliche (kostenlose oder kommerzielle)
Lösungen gibt, die man einsetzen könne. Vielleicht findet
Gruppe 2 allerdings keine Lösung, die zum Problem paßt.
Dann entwickelt man es selbst und dann sehe ich aber auch
kein Problem damit, weil die Voraussetzung der
Eigenrecherche bereits erfüllt wurde.
Bestes Beispiel: Chart-Grafiken. Wenn ich zu Gruppe 1
gehöre, dann baue ich mir selbst eine Chart-Klasse und
tüftel wochenlang daran herum, weil es mich reizt. Bin ich
aber der Gruppe 2 zugehörig, d.h. die Applikation für den
Kunden spuckt Statistiken aus und die sollen jetzt
schlipsträgerkonform in Grafik ausgegeben werden, und suche
*nicht* nach bereits vorhandenen Chart-Klassen, dann gehöre
ich erschlagen. Denn gerade im Chart-Bereich gibt es
hervorragende Lösungen (ich favorisiere hier JPGraph[3],
wobei ich den Autor überreden will, seine Klasse auch
kommerziell lizenzieren zu können), die zunächst eines
näheren Blicks lohnen. Wenn ich ausführlich recherchiert
habe (üblicherweise zunächst Sourceforge.net und
freshmeat.net, evtl. Google und die üblichen verdächtigen
Scriptsammlungs-Sites) und keine passende Lösung für mein
Problem gefunden habe, dann rechtfertigt es IMHO eine
Eigenentwicklung.
[2]: kleine Anekdote. Mich rief neulich ein Gastwirt an,
der nebenher noch bißchen Webgeschichten macht. Er wollte
mich für ein Projekt (mit Umsatzbeteiligung, schon mal sehr
unseriös) werben, einen regionalen Marktplatz. Im Verlauf
des Gesprächs stellte sich heraus, dass er eine
"Revolution" plane. Er wolle ganz Europa mit diesen
regionalen Marktplätzen bepflastern. Hätte er vorher mit
anderen geredet, wüßte er, dass der Hype um regionale Malls
bereits vorbei ist und insbesondere in Deutschland oftmals
bereits durch die Sparkassen (als Beteiligungsgesellschaft)
besetzt ist.
[3]: http://www.aditus.nu/jpgraph/, man beachte
insbesondere das Tutorial zum Erstellen von
Gantt-Diagrammen. Andere leistungsfähige Klassen sind
Vagrant und PHPlot, wobei JPGraph offensichtlich die
leistungsfähigste zu sein scheint.
--
PHP-Support * realitätsnahe Performance-Messungen mit Code-Analyse
Webapplikationsentwicklung * PHP-Schulungen * Consulting
0700-THINKPHP -*- bjoern_(at)_thinkphp.de
php::bar PHP Wiki - Listenarchive