objektorientiert?
Heiko Warnken
wann hat die opjektorientierte Programmierung mit PHP 5 Vorteile und
welche sind das?
Ich beschäftige mich seit etwa 3 Tagen mit der objektorientierten
Programmierung. Soll heißen: ich lese mich da gerade etwas ein.
Ich habe u. a. gelesen, dass die objektorientierte Abarbeitung von
Scripts länger dauern soll, als eine sequentielle Abarbeitung der
Scripts. Ist da was dran?
Gruß
Heiko
Ulf K@dner
> wann hat die opjektorientierte Programmierung mit PHP 5 Vorteile und
> welche sind das?
Die meisten generell bekannten OOP-Vorteile, unabhängig von PHP.
> Ich beschäftige mich seit etwa 3 Tagen mit der objektorientierten
> Programmierung. Soll heißen: ich lese mich da gerade etwas ein.
Sehr gut. Was liest Du denn diesbezüglich das Dir Vorteile von OOP
verborgen bleiben?
> Ich habe u. a. gelesen, dass die objektorientierte Abarbeitung von
> Scripts länger dauern soll, als eine sequentielle Abarbeitung der
> Scripts. Ist da was dran?
Klar. Aber nichts was Dich interessieren sollte. Da gehts nur um
performancekritische Szenarien die nur äußerst selten Relevanz haben.
MfG, Ulf
Heiko Warnken
> Am 18.01.2011 08:11, schrieb Heiko Warnken:
>
>> wann hat die opjektorientierte Programmierung mit PHP 5 Vorteile und
>> welche sind das?
>
> Die meisten generell bekannten OOP-Vorteile, unabhängig von PHP.
Ok. Dennoch ist die Programmierweise anscheinend mit keiner anderen
Sprache zu vergleichen, oder?
>
>> Ich beschäftige mich seit etwa 3 Tagen mit der objektorientierten
>> Programmierung. Soll heißen: ich lese mich da gerade etwas ein.
>
> Sehr gut. Was liest Du denn diesbezüglich das Dir Vorteile von OOP
> verborgen bleiben?
Z. B.: http://www.peterkropff.de/site/php/oop.htm
Gibt es etwas empfehlenswertes, was ich online studieren kann?
>
>> Ich habe u. a. gelesen, dass die objektorientierte Abarbeitung von
>> Scripts länger dauern soll, als eine sequentielle Abarbeitung der
>> Scripts. Ist da was dran?
>
> Klar. Aber nichts was Dich interessieren sollte. Da gehts nur um
> performancekritische Szenarien die nur äußerst selten Relevanz haben.
Aha, ok.
Aber sag' mal, ist es nicht möglich, z. B. ein Eingabefeld als Objekt
anzusprechen? So bin ich es z. B. von VB gewohnt. Hier lege ich ein
Textfeld auf eine Form und dieses Textfeld enthält bereits definierte
Eigenschaften und Methoden.
Wenn ich das aber in PHP versuchen will, brauche ich wohl damit gar
nicht erst anfangen, oder?
Oder ist es u. U. möglich,
<input type="text" name="Textfeld" id="text1">
in PHP als Objekt anzusprechen? Etwa in der Form
<?PHP
$text1->maxlength=32;
$text1.size=33;
?>
und das ganze dann z. B. mit
<?PHP
$textinhalt = $text1.value;
?>
auszulesen? Oder z. B. bereits während der Eingabe nur bestimmte Zeichen
zuzulassen?
<?PHP
$text1->allowedChar="0123456789";
?>
Aber bei diesen Vorgehensweisen stoße ich ohne JavaScript auf die
Grenzen, da es sich bei PHP schließlich um eine Serverbasierte Sprache
handelt, oder?
Ließe sich soetwas besser in ASP realisieren?
Gruß
Heiko
Michael Fesser
>Aber sag' mal, ist es nicht möglich, z. B. ein Eingabefeld als Objekt
>anzusprechen? So bin ich es z. B. von VB gewohnt. Hier lege ich ein
>Textfeld auf eine Form und dieses Textfeld enthält bereits definierte
>Eigenschaften und Methoden.
Zwischen einer Desktop- und einer Webanwendung bestehen schon ein paar
Unterschiede, prinzipiell kann man aber natürlich auch bei letzterer
Formulare objektorientiert aufbauen.
>Wenn ich das aber in PHP versuchen will, brauche ich wohl damit gar
>nicht erst anfangen, oder?
>
>Oder ist es u. U. möglich,
>
><input type="text" name="Textfeld" id="text1">
>
>in PHP als Objekt anzusprechen? Etwa in der Form
><?PHP
>$text1->maxlength=32;
>$text1.size=33;
>?>
>und das ganze dann z. B. mit
><?PHP
>$textinhalt = $text1.value;
>?>
>auszulesen?
Geht alles, eine entsprechende Klassenbibliothek vorausgesetzt (und '->'
statt '.')
Es gibt zahlreiche fertige Formularklassen und -bibliotheken für PHP.
Ich kann jetzt allerdings keine empfehlen, da ich hier eigene Klassen
verwende. Ich kann an meine Formularobjekte noch beliebige Validatoren
dranhängen, so daß sich das Verarbeiten der Formulardaten dann grob so
darstellt:
if ($form->isValid()) {
$textinhalt = $form->text1->getValue();
…
}
Also ziemlich genau wie obiger Ansatz und somit völlig problemlos mit
PHP machbar.
>Oder z. B. bereits während der Eingabe nur bestimmte Zeichen
>zuzulassen?
Das allerdings fällt in den Aufgabenbereich von JavaScript. PHP bekommt
ja nur die fertige Eingabe, JS hingegen kann direkt „dazwischenfunken“.
><?PHP
>$text1->allowedChar="0123456789";
>?>
Auch möglich, das müßte dann bei der Ausgabe allerdings in ein
entsprechendes JavaScript umgewandelt werden (oder ggf. HTML5).
>Aber bei diesen Vorgehensweisen stoße ich ohne JavaScript auf die
>Grenzen, da es sich bei PHP schließlich um eine Serverbasierte Sprache
>handelt, oder?
Korrekt.
>Ließe sich soetwas besser in ASP realisieren?
Das läuft doch genauso auf dem Server. Wenn etwas direkt im Browser bei
der Eingabe geprüft werden soll, dann ist immer JS erforderlich, egal
was auf dem Server läuft.
Micha
Gregor Kofler
> Am 18.01.2011 11:31, schrieb Ulf K@dner:
> > Am 18.01.2011 08:11, schrieb Heiko Warnken:
>>
>>> wann hat die opjektorientierte Programmierung mit PHP 5 Vorteile und
>>> welche sind das?
>>
>> Die meisten generell bekannten OOP-Vorteile, unabhängig von PHP.
>
> Ok. Dennoch ist die Programmierweise anscheinend mit keiner anderen
> Sprache zu vergleichen, oder?
Doch. Mit fast jeder anderen objektorientierten.
> Aber sag' mal, ist es nicht möglich, z. B. ein Eingabefeld als Objekt
> anzusprechen? So bin ich es z. B. von VB gewohnt. Hier lege ich ein
> Textfeld auf eine Form und dieses Textfeld enthält bereits definierte
> Eigenschaften und Methoden.
> Wenn ich das aber in PHP versuchen will, brauche ich wohl damit gar
> nicht erst anfangen, oder?
Du meinst HTML-Formular-Elemente? Die sind nichts anderes als
Zeichenketten. Funktionalität derselben bastelt dein Browser.
> Oder ist es u. U. möglich,
>
> <input type="text" name="Textfeld" id="text1">
>
> in PHP als Objekt anzusprechen? Etwa in der Form
> <?PHP
> $text1->maxlength=32;
> $text1.size=33;
Punktnotation ist nicht. Aber sonst: Sicher. Man schreibt eine Klasse
FormInput, die wird passend instanziert, und mit entsprechenden Methoden
manipuliert. Eine display() oder render() Methode spuckt deinen fertigen
HTML-String aus.
> und das ganze dann z. B. mit
> <?PHP
> $textinhalt = $text1.value;
> ?>
> auszulesen? Oder z. B. bereits während der Eingabe nur bestimmte Zeichen
> zuzulassen?
> <?PHP
> $text1->allowedChar="0123456789";
> ?>
> Aber bei diesen Vorgehensweisen stoße ich ohne JavaScript auf die
> Grenzen, da es sich bei PHP schließlich um eine Serverbasierte Sprache
> handelt, oder?
Korrekt. Theoretisch könnte deine PHP-Klasse auch das passende JS dazu
generieren. Da das clientseitige JS aber ohnedies nur kosmetisch oder
"usability-bequem" ist, kann es auch ruhig sonstwo in irgendwelchen
Templates verbleiben. Die echte Validierung kann (nach dem $_POST-Werte
am Server vorliegen) auch in deiner Klasse erfolgen.
> Ließe sich soetwas besser in ASP realisieren?
Läuft ASP bei deinem Hoster? Ansonsten: Eigentlich nein. Sind doch
Active *Server* Pages.
Gregor
Ulf K@dner
> Ok. Dennoch ist die Programmierweise anscheinend mit keiner anderen
> Sprache zu vergleichen, oder?
Die Sprachsyntax ist nur der "Zucker"! Die Grundidee von OOP bleibt die
gleiche.
> Z. B.: http://www.peterkropff.de/site/php/oop.htm
> Gibt es etwas empfehlenswertes, was ich online studieren kann?
Ja definitiv! Das folgende Buch war mal mein Lieblingsbuck zu PHP
mittlerweile gibts das als Online-Lektüre
<URL:http://www.professionelle-softwareentwicklung-mit-php5.de/>
Wirklich gerade zum Einstieg oder Auffrischen von OOP keine schlechter
Startpunkt.
> Aber sag' mal, ist es nicht möglich, z. B. ein Eingabefeld als Objekt
> anzusprechen?
Ansprechen sicher nicht, aber ausgeben sicher, wenn Du es in ein Objekt
kapselst.
> So bin ich es z. B. von VB gewohnt. Hier lege ich ein
> Textfeld auf eine Form und dieses Textfeld enthält bereits definierte
> Eigenschaften und Methoden.
Gibts fertige Klassen sicher irgendwo aber ich nutze genau wie viele
andere mein eigenes Framework und habe keine ahnung was da so im Web
rumwabbert.
> Wenn ich das aber in PHP versuchen will, brauche ich wohl damit gar
> nicht erst anfangen, oder?
>
> Oder ist es u. U. möglich,
>
> <input type="text" name="Textfeld" id="text1">
>
> in PHP als Objekt anzusprechen? Etwa in der Form
> <?PHP
> $text1->maxlength=32;
> $text1.size=33;
> ?>
Klar schreib Dir die zugehörige Klassenstrukturen selbst.
> Aber bei diesen Vorgehensweisen stoße ich ohne JavaScript auf die
> Grenzen, da es sich bei PHP schließlich um eine Serverbasierte Sprache
> handelt, oder?
Das ist richtig.
> Ließe sich soetwas besser in ASP realisieren?
Auch nicht. sowas kannst ausschließlich mit JS bauen oder mit Zeug wie
Actionscipt in Flash. Aber das letztere will man nicht wirklich.
MfG, Ulf
Thomas 'PointedEars' Lahn
^^^^^^^^^^
Da ist was kapott, was früher mal ganz war.
> Am 18.01.2011 16:58, schrieb Heiko Warnken:
>> Aber bei diesen Vorgehensweisen stoße ich ohne JavaScript auf die
>> Grenzen, da es sich bei PHP schließlich um eine Serverbasierte Sprache
>> handelt, oder?
>
> Das ist richtig.
Nein, ist es nicht! PHP und (landläufig) "JavaScript" sind erstmal nur
Programmiersprachen (bzw. letzteres ist eigentlich eine Gruppe einander
ähnlicher solcher¹). Jede Programmiersprachen kann sowohl auf einem Client
als auch auf einem Server eingesetzt werden. Nur im Web ist es so, dass
sich PHP selten auf der Clientseite findet. "JavaScript" findet man auf
beiden Seiten.
>> Ließe sich soetwas besser in ASP realisieren?
>
> Auch nicht. sowas kannst ausschließlich mit JS bauen
Das ist kein Gegensatz, auch weil "JS" nicht ausschliesslich clientseitig
ist (was gern unterschlagen wird). Zum Thema Formularvalidierung hat z.B.
ASP .NET (bei ASP Classic weiss ich es nicht) diesen "ajaxoiden" Ansatz
(postback), bei dem man serverseitig nur die Controls und RegExps definieren
muss und der Rest wird geeignet generiert. Schön und kompatibel ist aber
meist anders.
PointedEars
___________
¹ Die weitverbreitetsten sind unter <http://PointedEars.de/es-matrix>
erfasst; ActionScript werde ich bei Gelegenheit noch ergänzen.
--
Es ist ein ohne Sinn und Verstand ausgeschnittener Teil von invalidem
HTML mit in MSIE funktionierendem JScript (allerdings fehlen hier zum
Funktionieren erforderliche Teile), erzeugt von Micros~1 AffrontPage.
(Dietmar Meier in <aq8afp$7cc0b$1...@ID-3767.news.dfncis.de>)
Alexander Schestag
> Nur im Web ist es so, dass sich PHP selten auf der Clientseite findet.
Hast du mal ein praktisch wirklich relevantes Beispiel für dieses "selten"?
Grüße,
Alex
Ulf K@dner
> ^^^^^^^^^^
> Da ist was kapott, was früher mal ganz war.
>
>> Am 18.01.2011 16:58, schrieb Heiko Warnken:
>>> Aber bei diesen Vorgehensweisen stoße ich ohne JavaScript auf die
>>> Grenzen, da es sich bei PHP schließlich um eine Serverbasierte Sprache
>>> handelt, oder?
>>
>> Das ist richtig.
>
> Nein, ist es nicht! PHP und (landläufig) "JavaScript" sind erstmal nur
> Programmiersprachen (bzw. letzteres ist eigentlich eine Gruppe einander
> ähnlicher solcher¹). Jede Programmiersprachen kann sowohl auf einem Client
> als auch auf einem Server eingesetzt werden.
Ohjee! Hier (und das ist wohl jedem außer Dir klar) geht es gerade um
klassische webserverbasierte Systeme. Genau darüber redet der OP.
>>> Ließe sich soetwas besser in ASP realisieren?
>>
>> Auch nicht. sowas kannst ausschließlich mit JS bauen
>
> Das ist kein Gegensatz
<Loriot>Ach was?</Loriot>
> auch weil "JS" nicht ausschliesslich clientseitig
> ist (was gern unterschlagen wird).
Das steht hier garnicht zur Diskusion.
MfG, Ulf
Thomas 'PointedEars' Lahn
Ja. Google ist Dein Freund. [psf 6.1]
PointedEars
--
> In [einem Popup] soll sich ein Link befinden, der im Hauptfenster
> ausgeführt werden soll. Habt ihr ne Ahnung, wie man das anstellt?
Links werden niemals ausgeführt, denn es sind keine Hunde, mit denen man
Gassi geht. (Georg Maaß in dcljs <aop009$ooab4$1...@ID-3551.news.dfncis.de>)
Thomas 'PointedEars' Lahn
^
Was soll das?
> Am 19.01.2011 00:35, schrieb Thomas 'PointedEars' Lahn:
>> Ulf K@dner wrote:
>>> Am 18.01.2011 16:58, schrieb Heiko Warnken:
>>>> Aber bei diesen Vorgehensweisen stoße ich ohne JavaScript auf die
>>>> Grenzen, da es sich bei PHP schließlich um eine Serverbasierte Sprache
>>>> handelt, oder?
>>> Das ist richtig.
>> Nein, ist es nicht! PHP und (landläufig) "JavaScript" sind erstmal nur
>> Programmiersprachen (bzw. letzteres ist eigentlich eine Gruppe einander
>> ähnlicher solcher¹). Jede Programmiersprachen kann sowohl auf einem
>> Client als auch auf einem Server eingesetzt werden.
>
> Ohjee! Hier (und das ist wohl jedem außer Dir klar) geht es gerade um
> klassische webserverbasierte Systeme. Genau darüber redet der OP.
Das ändert genau nichts daran, dass es sich bei PHP "schliesslich" _nicht_
(ausschliesslich) "um eine Serverbasierte Sprache handelt".
>>>> Ließe sich soetwas besser in ASP realisieren?
>>> Auch nicht. sowas kannst ausschließlich mit JS bauen
>> Das ist kein Gegensatz
>
> <Loriot>Ach was?</Loriot>
<Loriot>Die Ente bleibt draussen!</Loriot>
>> auch weil "JS" nicht ausschliesslich clientseitig
>> ist (was gern unterschlagen wird).
>
> Das steht hier garnicht zur Diskusion.
Wenn Du behauptest, dass es sich nicht "besser in ASP", sondern
"ausschliesslich mit JS" (lies: "weil clientseitig") realisieren
lässt, so ist in mehrfacher Hinsicht falsch.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Alexander Schestag
> Alexander Schestag wrote:
>
>> Am 19.01.2011 00:35, schrieb Thomas 'PointedEars' Lahn:
>>> Nur im Web ist es so, dass sich PHP selten auf der Clientseite findet.
>>
>> Hast du mal ein praktisch wirklich relevantes Beispiel für dieses
>> "selten"?
>
> Ja. Google ist Dein Freund. [psf 6.1]
Sehr witzige Antwort. Wer Dinge in den Raum stellt, sollte sie auch
belegen können. Aber zunächst sollte man überhaupt mal fragen, was "auf
der Clientseite" heißt. Wenn damit beispielsweise Webmail- oder andere
webbasierte Clients, die in PHP realisiert sind, gemeint sind, gibt es
natürlich Beispiele wie Sand am Meer. Hier ist es jedoch nach wie vor
so, daß PHP serverseitig, sprich durch einen Webserver interpretiert
wird. Wenn damit jedoch die clientseitige Interpretation etwa im Browser
gemeint ist, findet sich das - logischerweise - nur als Aprilscherz:
http://www.php-resource.de/forum/showthread/t-18208.html.
Alex
Thomas 'PointedEars' Lahn
> Am 19.01.2011 11:27, schrieb Thomas 'PointedEars' Lahn:
>> Alexander Schestag wrote:
>>> Am 19.01.2011 00:35, schrieb Thomas 'PointedEars' Lahn:
>>>> Nur im Web ist es so, dass sich PHP selten auf der Clientseite findet.
>>> Hast du mal ein praktisch wirklich relevantes Beispiel für dieses
>>> "selten"?
>>
>> Ja. Google ist Dein Freund. [psf 6.1]
>
> Sehr witzige Antwort.
Das freut mich.
> Wer Dinge in den Raum stellt, sollte sie auch belegen können. […]
Das kann ich auch. Hast Du Google nach "client-side PHP" befragt?
Alexander Schestag
> Alexander Schestag wrote:
>
>> Sehr witzige Antwort.
>
> Das freut mich.
>
>> Wer Dinge in den Raum stellt, sollte sie auch belegen können. […]
>
> Das kann ich auch. Hast Du Google nach "client-side PHP" befragt?
Jo. Fieseln wir das mal auseinander. Ich fragte nach wirklich praktisch
relevanten Beispielen. Kein einziges der Beispiele ist wirklich
praktisch relevant.
- In diesem Thread ist weder von PHP-CLI noch von PHP-GTK die Rede.
- Diese "Activescript SAPI for PHP" halte ich als IE-Insellösung für
völlig irrelevant.
- Diese Geschichte von Carvalho findet praktisch relevanten Einsatz? Wo?
Alex
Michael Fesser
>Am 19.01.2011 11:27, schrieb Thomas 'PointedEars' Lahn:
>> Alexander Schestag wrote:
>>
>>> Am 19.01.2011 00:35, schrieb Thomas 'PointedEars' Lahn:
>>>> Nur im Web ist es so, dass sich PHP selten auf der Clientseite findet.
>>>
>>> Hast du mal ein praktisch wirklich relevantes Beispiel für dieses
>>> "selten"?
>>
>> Ja. Google ist Dein Freund. [psf 6.1]
>
>Sehr witzige Antwort. Wer Dinge in den Raum stellt, sollte sie auch
>belegen können. Aber zunächst sollte man überhaupt mal fragen, was "auf
>der Clientseite" heißt.
Ausführung des Codes im Browser.
>Wenn damit beispielsweise Webmail- oder andere
>webbasierte Clients, die in PHP realisiert sind, gemeint sind, gibt es
>natürlich Beispiele wie Sand am Meer.
Sowas ist damit natürlich nicht gemeint, denn der Programmcode wird
hierbei auf dem Server ausgeführt.
>Hier ist es jedoch nach wie vor
>so, daß PHP serverseitig, sprich durch einen Webserver interpretiert
>wird. Wenn damit jedoch die clientseitige Interpretation etwa im Browser
>gemeint ist, findet sich das - logischerweise - nur als Aprilscherz:
>http://www.php-resource.de/forum/showthread/t-18208.html.
Was heißt hier „logischerweise“? HTML bietet schon seit langem die
Möglichkeit zur Einbindung beliebiger client-seitiger Sprachen; die
Spezifikation selbst führt TCL und VBScript als Beispiele an. Und es gab
tatsächlich mal ein PHP-Plugin für den IE. Zwar mehr ein Proof-of-
concept, aber immerhin. Rein technisch spricht auch nichts dagegen.
Micha
Michael Fesser
>Am 19.01.2011 12:40, schrieb Thomas 'PointedEars' Lahn:
>> Alexander Schestag wrote:
>>
>>> Sehr witzige Antwort.
>>
>> Das freut mich.
>>
>>> Wer Dinge in den Raum stellt, sollte sie auch belegen können. […]
>>
>> Das kann ich auch. Hast Du Google nach "client-side PHP" befragt?
>
>Jo. Fieseln wir das mal auseinander. Ich fragte nach wirklich praktisch
>relevanten Beispielen. Kein einziges der Beispiele ist wirklich
>praktisch relevant.
Darum ging es auch nicht. Der knackende Punkt war Ulfs Aussage bzw. die
Bestätigung, PHP wäre eine serverbasierte Sprache (zugegeben, etwas aus
dem Zusammenhang gerissen). Das ist so in dieser Absolutheit falsch.
Genausowenig ist JS eine clientbasierte Sprache, auch wenn es zum
Großteil dort eingesetzt wird. Man kann praktisch jede Programmier-
sprache in beliebigen Umgebungen einsetzen, sofern dort Interpreter bzw.
andere Ausführungsmechanismen existieren.
>- In diesem Thread ist weder von PHP-CLI noch von PHP-GTK die Rede.
Aber bereits damit wäre die Behauptung widerlegt.
PHP wird zwar überwiegend serverseitig eingesetzt, ist aber nicht auf
diesen Anwendungszweck beschränkt. QED.
Letztlich bleibt aber nur zu sagen:
split('', $hairs);
Micha
Thomas 'PointedEars' Lahn
> Am 19.01.2011 12:40, schrieb Thomas 'PointedEars' Lahn:
>> Alexander Schestag wrote:
>>> Wer Dinge in den Raum stellt, sollte sie auch belegen können. […]
>> Das kann ich auch. Hast Du Google nach "client-side PHP" befragt?
>
> Jo. Fieseln wir das mal auseinander. Ich fragte nach wirklich praktisch
> relevanten Beispielen. Kein einziges der Beispiele ist wirklich
> praktisch relevant.
Angenommen das wäre so, änderte das genau nichts an der Richtigkeit meiner
Aussage. Bitte Logikmodul justieren.
> - In diesem Thread ist weder von PHP-CLI noch von PHP-GTK die Rede.
Und?
> - Diese "Activescript SAPI for PHP" halte ich als IE-Insellösung für
> völlig irrelevant.
Deine unmassgebliche Meinung. Allerdings wäre eine IE-Insellösung eine
Bestätigung für meine Aussage, nicht wahr?
> - Diese Geschichte von Carvalho findet praktisch relevanten Einsatz? Wo?
Das weiss ich nicht. Es ist jedoch davon ausgegangen werden, dass es zwar
selten Anwendung findet, aber _nicht_ niemals. Und das ist genau mein
Punkt.
PointedEars
--
Clientseitig geht das nicht wirklich, weil der Browser selbst keine
Mails verschicken kann und das Kooperieren mit Mailprogrammen eher
in ein Kollabieren entartet.
(Georg Maaß in dcljs <aoh6vi$mbrnu$4...@ID-3551.news.dfncis.de>)
Thomas 'PointedEars' Lahn
> Am 19.01.2011 12:40, schrieb Thomas 'PointedEars' Lahn:
>> Alexander Schestag wrote:
>>> Wer Dinge in den Raum stellt, sollte sie auch belegen können. […]
>> Das kann ich auch. Hast Du Google nach "client-side PHP" befragt?
>
> Jo. Fieseln wir das mal auseinander. Ich fragte nach wirklich praktisch
> relevanten Beispielen. Kein einziges der Beispiele ist wirklich
> praktisch relevant.
Angenommen das wäre so, änderte das genau nichts an der Richtigkeit meiner
Aussage. Bitte Logikmodul justieren.
> - In diesem Thread ist weder von PHP-CLI noch von PHP-GTK die Rede.
Und?
> - Diese "Activescript SAPI for PHP" halte ich als IE-Insellösung für
> völlig irrelevant.
Deine unmassgebliche Meinung. Allerdings wäre eine IE-Insellösung eine
Bestätigung für meine Aussage, nicht wahr?
> - Diese Geschichte von Carvalho findet praktisch relevanten Einsatz? Wo?
Das weiss ich nicht.
Es kann jedoch davon ausgegangen werden, dass PHP im Web zwar selten
Anwendung findet (im von Carvalho gezeigten Fall wahrscheinlich zu Recht),
Alexander Schestag
> .oO(Alexander Schestag)
>
>> Am 19.01.2011 12:40, schrieb Thomas 'PointedEars' Lahn:
>>> Alexander Schestag wrote:
>>>
>>>> Sehr witzige Antwort.
>>>
>>> Das freut mich.
>>>
>>>> Wer Dinge in den Raum stellt, sollte sie auch belegen können. […]
>>>
>>> Das kann ich auch. Hast Du Google nach "client-side PHP" befragt?
>>
>> Jo. Fieseln wir das mal auseinander. Ich fragte nach wirklich praktisch
>> relevanten Beispielen. Kein einziges der Beispiele ist wirklich
>> praktisch relevant.
>
> Darum ging es auch nicht.
Doch, genau darum ging es mir, und darauf hat Thomas geantwortet! Wie
kommst du bitte dazu, mir vorschreiben zu wollen, worum es mir geht?
Alex
Alexander Schestag
> .oO(Alexander Schestag)
>
>> so, daß PHP serverseitig, sprich durch einen Webserver interpretiert
>> wird. Wenn damit jedoch die clientseitige Interpretation etwa im Browser
>> gemeint ist, findet sich das - logischerweise - nur als Aprilscherz:
>> http://www.php-resource.de/forum/showthread/t-18208.html.
>
> Was heißt hier „logischerweise“? HTML bietet schon seit langem die
> Möglichkeit zur Einbindung beliebiger client-seitiger Sprachen; die
> Spezifikation selbst führt TCL und VBScript als Beispiele an. Und es gab
> tatsächlich mal ein PHP-Plugin für den IE. Zwar mehr ein Proof-of-
> concept, aber immerhin. Rein technisch spricht auch nichts dagegen.
Klar ist das technisch möglich, nur ging's mir darum nicht. Noch einmal:
Ich fragte nach wirklich praktisch relevanten Beispielen. Eine
Insellösung für den IE ist praktisch völlig irrelevant. Sprich: Solange
es da nichts gibt, was zumindest alle großen Browserhersteller
implementieren, hat client-seitiges PHP für Webanwendungen genau gar
keine praktische Relevanz.
Aber diese Fokussierung auf die praktische Relevanz scheint den
Hardcore-Nerd wohl zu überfordern. Versteh ich. ;-)
Grüße,
Alex
Thomas 'PointedEars' Lahn
Alexander Schestag wrote:
> Am 19.01.2011 12:40, schrieb Thomas 'PointedEars' Lahn:
>> Alexander Schestag wrote:
>>> Wer Dinge in den Raum stellt, sollte sie auch belegen können. […]
>> Das kann ich auch. Hast Du Google nach "client-side PHP" befragt?
>
> Jo. Fieseln wir das mal auseinander. Ich fragte nach wirklich praktisch
> relevanten Beispielen. Kein einziges der Beispiele ist wirklich
> praktisch relevant.
Angenommen das wäre so, änderte das genau nichts an der Richtigkeit meiner
Aussage. Bitte Logikmodul justieren.
> - In diesem Thread ist weder von PHP-CLI noch von PHP-GTK die Rede.
Und?
> - Diese "Activescript SAPI for PHP" halte ich als IE-Insellösung für
> völlig irrelevant.
Deine unmassgebliche Meinung. Allerdings wäre eine IE-Insellösung eine
Bestätigung für meine Aussage, nicht wahr?
> - Diese Geschichte von Carvalho findet praktisch relevanten Einsatz? Wo?
Das weiss ich nicht.
Es kann jedoch davon ausgegangen werden, dass PHP im Web zwar selten
clientseitig Anwendung findet (im von Carvalho gezeigten Fall wahrscheinlich
Alexander Schestag
> Alexander Schestag wrote:
>
>> Am 19.01.2011 12:40, schrieb Thomas 'PointedEars' Lahn:
>>> Alexander Schestag wrote:
>>>> Wer Dinge in den Raum stellt, sollte sie auch belegen können. […]
>>> Das kann ich auch. Hast Du Google nach "client-side PHP" befragt?
>>
>> Jo. Fieseln wir das mal auseinander. Ich fragte nach wirklich praktisch
>> relevanten Beispielen. Kein einziges der Beispiele ist wirklich
>> praktisch relevant.
>
> Angenommen das wäre so, änderte das genau nichts an der Richtigkeit meiner
> Aussage. Bitte Logikmodul justieren.
Wenn du mir antwortest, solltest du schon die Fragen beachten, die ich
stelle. Ich hatte dich um praktisch relevante Beispiele gebeten.
>> - In diesem Thread ist weder von PHP-CLI noch von PHP-GTK die Rede.
>
> Und?
Ich bezog mich mit der Bitte nach praktisch relevanten Beispielen auf
deine Aussage, PHP würde sich im Web "selten auf der Clientseite"
befinden. Damit ist der Bezug auf CLI und GTK definitiv raus.
>> - Diese "Activescript SAPI for PHP" halte ich als IE-Insellösung für
>> völlig irrelevant.
>
> Deine unmassgebliche Meinung. Allerdings wäre eine IE-Insellösung eine
> Bestätigung für meine Aussage, nicht wahr?
Ja, aber keine Antwort auf meine Frage, auf die dein
Google-Suchvorschlag kam.
>> - Diese Geschichte von Carvalho findet praktisch relevanten Einsatz? Wo?
>
> Das weiss ich nicht. Es ist jedoch davon ausgegangen werden, dass es zwar
> selten Anwendung findet, aber _nicht_ niemals. Und das ist genau mein
> Punkt.
Mein Punkt war aber ein anderer, und auf den geht diese
Meinungsverschiedenheit zurück.
Halten wir also fest: Du konntest mir meine Frage nach praktisch
relevanten Beispielen für clientseitiges PHP, die ich aus reinem
Interesse und nicht als Widerspruch zu deiner Aussage gestellt habe,
nicht beantworten. Das hättest du mit einem einfachen "Weiß ich nicht"
einfacher haben können.
Grüße,
Alex
Alexander Schestag
> [nochmal Cancel& Supersedes, sorry]
Siehe meine Antwort darauf. Ich wiederhol mich jetzt nicht nochmal.
Alex
Thomas 'PointedEars' Lahn
> Am 19.01.2011 13:44, schrieb Thomas 'PointedEars' Lahn:
>> Alexander Schestag wrote:
>>> - Diese "Activescript SAPI for PHP" halte ich als IE-Insellösung für
>>> völlig irrelevant.
>>
>> Deine unmassgebliche Meinung. Allerdings wäre eine IE-Insellösung eine
>> Bestätigung für meine Aussage, nicht wahr?
>
> Ja, aber keine Antwort auf meine Frage, auf die dein
> Google-Suchvorschlag kam.
Was praktisch relevant ist bestimmst aber nicht Du!
> Halten wir also fest: Du konntest mir meine Frage nach praktisch
> relevanten Beispielen für clientseitiges PHP, die ich aus reinem
> Interesse und nicht als Widerspruch zu deiner Aussage gestellt habe,
> nicht beantworten. Das hättest du mit einem einfachen "Weiß ich nicht"
> einfacher haben können.
Du hast ja so Recht … und ich meine Ruhe.
PointedEars
--
> ECMAScript ist somit nicht mit dem W3C-DOM kompatibel. Richtig?
Hunde sind zu Fischsuppe nicht kompatibel. Nachts ist es kälter als
draußen. Wo ist der Zusammenhang zwischen W3C-DOM unter z.B. Java oder
PHP und ECMA-Script? (Georg Maaß in dcljs <3D118071...@vnett.de>)
Wolfram Hubert
prozedurale PHP-Programmierung:
*Vorteil
- Weniger Komplexität, dadurch leichterer Einstieg
- besonders geeignet, um in statische Seiten kleinste nichtstatische
Inhaltsbrocken, z.B. Anzeige des aktuellen Datums, zu realisieren.
Betrachte dazu die Anfänge von PHP. (Ursprünglich war PHP eine
Sammlung von Perlskripten, zu einer Zeit, als PHP noch Personal Home
Page Tools hieß)
*Nachteil
- Abbildung von komplexen Gebilden nicht möglich (Mit Objekten lassen
sich komplexere Gebilde abbilden)
objektorientierte PHP-Programmierung:
*Vorteil
- komplexe Gebilde können besser im Code abgebildet werden
- bei großen komplexen Gebilden ist mehr Übersichtlichkeit möglich
- größere Ausdruckstärke, z.B. ein Ding darf genau nur einmal
existieren (Anwendung des Singleton-Muster)
- Eigenschaften (Klassenvariablen) und Funktionen (Methoden) von
Gebilden lassen sich verbinden, sodaß aus dem Code hervor geht, was
man (daher die Eigenschaften) wie (daher die Methoden) ändern kann.
Eigenschaften und Funktionen bilden eine Einheit und ist als Objekt
ansprechbar. Die Daten des Objektes lassen sich kapseln, sodass die
Gefahr minimiert werden kann, dass Daten unabsichtlich verändert
werden.
*Nachteil
- Komplexer, weil es gegenüber der prozeduralen Programmierung mehr
Sprachkonstrukte zum Definieren von Abbildungen existieren. Beispiel:
extends - subclass erbt Eigenschaften und Funktionen (Methoden) der
superclass (dies ohne das Code dupliziert werden muss), final -
Steuerung der Methodenüberschreibung (hier wird dies verhindert),
interface - Beschreibung von Schnittstellen, Steuerung der
Sichtbarkeiten wie protected, usw.
- Weil die objektorientierte Programmierung sehr komplexe Dinge
abbilden kann, kann zur Strukturierung und Codeverschlankung die
vielen Entwurfsmuster der OOP eingesetzt werden. Z.B.: Strategy-
Muster, Observer-Muster, Decorator-Muster, Singleton-Muster usw.
Prinzipiell ist die objektorientierte Abarbeitung genauso schnell wie
die der prozeduralen Abarbeitung. Wenn Du höchstperformante Dinge
machen möchtest, dann ist eine maschinennahe Programmierung die beste.
Nimm dazu Assembler ;-) Nein im Ernst. Für das Beschreiben von
komplexen Gebilden oder "Ich möchte einfach nur, dass auf der Seite
das aktuelle Datum steht!" nimmt man eine Abstrahierung zur Maschine
(Register, RAM, Akkumulator(Das ist der Teil, mit dem man
Manupulationen an Bits und Bytes machen kann),Flash,EEPROM, usw.) in
Kauf, um 1. den Code trotz komplexer Abbildung noch lesen zu können
oder 2. um schnell mal in eine Seite das Datum aktuell darstellen zu
können.
Wie schnell eine bestimmte Funktionalität von der Maschine
abgearbeitet wird, hängt zum größten Teil von der eigenen Beherrschung
einer Programmiersprache ab.
Ich habe hier ein einfaches Beispiel, das so einfach ist, das hier
die Stärke der Objektorientierung nicht zum Tragen kommt ;-). Ich
weiß, man kann bei der prozeduralen PHP-Programmierungsbeispiel den
trim(...) Teil in eine extra Funktion auslagern. Aber wie oben gesagt,
OOP spielt seine Stärken bei komplexeren Dingen ihre Stärke aus.
prozedurale PHP-Programmierung:
<?php
function morning_greeting($name)
{
$greeting = trim("Good morning $name!"); // statt trim() könnte
hier eine komplexe Funktionalität stehen, z.B. eine Webservice- oder
eine Datenbankabfrage
return $greeting;
}
function midday_greeting($name)
{
$greeting = trim("Hello $name!"); // statt trim() könnte hier
eine komplexe Funktionalität stehen, z.B. eine Webservice- oder eine
Datenbankabfrage
return $greeting;
}
function evening_greeting($name)
{
$greeting = trim("Good evening $name!"); // statt trim() könnte
hier eine komplexe Funktionalität stehen, z.B. eine Webservice- oder
eine Datenbankabfrage
return $greeting;
}
echo midday_greeting('Heiko'); // Das ist einfach, oder?
?>
objektorientierte PHP-Programmierung:
<?php
abstract class AbstractGreeting
{
protected $greeting;
function build($name)
{
$string = trim($this->greeting.' '.$name); // statt trim()
könnte hier eine komplexe Funktionalität stehen, z.B. eine Webservice-
oder eine Datenbankabfrage
return $string;
}
}
class MiddayGreeting extends AbstractGreeting
{
function __construct()
{
$this->greeting = 'Hello';
}
}
class EveningGreeting extends AbstractGreeting
{
function __construct()
{
$this->greeting = 'Good evening';
}
}
class MorningGreeting extends AbstractGreeting
{
function __construct()
{
$this->greeting = 'Good morning';
}
}
$obj = new MiddayGreeting;
echo $obj->build('Heiko'); // Das geht auch, aber ist komplizierter
?>
Gruß
Wolfram
Ulf K@dner
> Ulf K@dner wrote:
>> Ohjee! Hier (und das ist wohl jedem außer Dir klar) geht es gerade um
>> klassische webserverbasierte Systeme. Genau darüber redet der OP.
>
> Das ändert genau nichts daran, dass es sich bei PHP "schliesslich" _nicht_
> (ausschliesslich) "um eine Serverbasierte Sprache handelt".
Das bestreitet ja auch keiner. Nur antworte ich ja nicht auf Dinge die
im aktuellen Context des Ops nicht von Relevanz sind oder nicht
nachgefragt wurden.
>>> auch weil "JS" nicht ausschliesslich clientseitig
>>> ist (was gern unterschlagen wird).
>>
>> Das steht hier garnicht zur Diskusion.
>
> Wenn Du behauptest, dass es sich nicht "besser in ASP", sondern
> "ausschliesslich mit JS" (lies: "weil clientseitig") realisieren
> lässt, so ist in mehrfacher Hinsicht falsch.
OK, mein Fehler so hatte ich das nicht interpretiert und auch nicht
gemeint. Hätte ich wohl präziser ausdrücken müssen.
MfG, Ulf
Jo Schulze
> wann hat die opjektorientierte Programmierung mit PHP 5 Vorteile und
> welche sind das?
Dieselben wie bei anderen OO Programmiersprachen.
> Ich beschäftige mich seit etwa 3 Tagen mit der objektorientierten
> Programmierung. Soll heißen: ich lese mich da gerade etwas ein.
>
> Ich habe u. a. gelesen, dass die objektorientierte Abarbeitung von
> Scripts länger dauern soll, als eine sequentielle Abarbeitung der
> Scripts. Ist da was dran?
Auch OO Skripte werden sequentiell abgearbeitet. Ja, ein gewisser
Overhaed besteht bei der Implemntierung von OO Sprachen, aber in einen
Rahmen der durch die bessere Strukturierung (hoffentlich) aufgewogen
wird.
Üblicherweise ist nicht PHP (oder eine andere Sprache) der Flaschenhals
bei Webapps sondern etwas anderes (DB, rewmote connects, whatever)
Guy Gaz
> - Diese "Activescript SAPI for PHP" halte ich als IE-Insellösung für
> völlig irrelevant.
Google ist aber auch ein Luder! Hat es Dir MozPHP z.B. total verschwiegen?
GG
--
“Ich habe viel mit Mario Basler gemeinsam.
Wir sind beide Fußballer, wir trinken beide gerne mal einen,
ich allerdings erst nach der Arbeit.” - F.M.
Guy Gaz
> Eine Insellösung für den IE ist praktisch völlig irrelevant.
Es gibt mehr.
> Sprich: Solange es da nichts gibt, was zumindest alle großen Browserhersteller
> implementieren, hat client-seitiges PHP für Webanwendungen genau gar
> keine praktische Relevanz.
Wenn Firma $A in ihrem Intranet die HTTP-UAs mit einem PHP-Interpreter
ausrüstet und fleissig PHP-Code durch diese Clients ausführen läßt, dann
hat das weshalb keine praktische Relevanz?
Guy Gaz
> Ohjee! Hier (und das ist wohl jedem außer Dir klar) geht es gerade um
> klassische webserverbasierte Systeme.
Mir nicht. Das hier ist doch dclpm, oder?
Es geht um PHP. Das ist eine Scriptsprache, die ich täglich
*clientseitig* einsetze - ohne jeglichen Webkontext.
Es geht mir hier nicht um die Historie von PHP, aber: PHP ist _auch_
eine universell /einsetzbare/ Scriptsprache.
Alexander Schestag
> Am 19.01.2011 13:47, schrieb Alexander Schestag:
>
>> Eine Insellösung für den IE ist praktisch völlig irrelevant.
>
> Es gibt mehr.
>
>> Sprich: Solange es da nichts gibt, was zumindest alle großen
>> Browserhersteller
>> implementieren, hat client-seitiges PHP für Webanwendungen genau gar
>> keine praktische Relevanz.
>
> Wenn Firma $A in ihrem Intranet die HTTP-UAs mit einem PHP-Interpreter
> ausrüstet und fleissig PHP-Code durch diese Clients ausführen läßt, dann
> hat das weshalb keine praktische Relevanz?
Intranets waren hier nicht das Thema. Aber so gesehen hast du recht, klar.
Alex
Ulf K@dner
> Am 19.01.2011 11:09, schrieb Ulf K@dner:
>> Ohjee! Hier (und das ist wohl jedem außer Dir klar) geht es gerade um
>> klassische webserverbasierte Systeme.
>
> Mir nicht. Das hier ist doch dclpm, oder?
> Es geht um PHP. Das ist eine Scriptsprache, die ich täglich
> *clientseitig* einsetze - ohne jeglichen Webkontext.
Du hast nicht verstanden um was es geht! Es geht nicht einfach um
clientside vs serverside! Sondern es gehn um clientside im Browser das
mit serverside interaggieren kann. Hättest Du das ganze Posting gelesen
wär Dir das klar denn darum gehts.
Da es PHP mal experimentell für sowas gab ist das auch nicht abwegig.
> Es geht mir hier nicht um die Historie von PHP, aber: PHP ist _auch_
> eine universell /einsetzbare/ Scriptsprache.
Das will sicher keiner bestreiten aber es ist weit am THema vorbei.
MfG, Ulf
Harald Stowasser
> Du hast nicht verstanden um was es geht! Es geht nicht einfach um
> clientside vs serverside! Sondern es gehn um clientside im Browser das
> mit serverside interaggieren kann. Hättest Du das ganze Posting gelesen
> wär Dir das klar denn darum gehts.
>
> Da es PHP mal experimentell für sowas gab ist das auch nicht abwegig.
>
>> Es geht mir hier nicht um die Historie von PHP, aber: PHP ist _auch_
>> eine universell /einsetzbare/ Scriptsprache.
>
> Das will sicher keiner bestreiten aber es ist weit am THema vorbei.
Um das Thema jetzt noch breiter zu treten, oute ich mich als Verteiler
der These das es Scriptsprachen eigentlich gar nicht gibt!
Eine Sprache kann eine Turingmaschine bauen, oder eben nicht. Punkt aus.
Harald
Ulf K@dner
> Um das Thema jetzt noch breiter zu treten, oute ich mich als Verteiler
> der These das es Scriptsprachen eigentlich gar nicht gibt!
>
> Eine Sprache kann eine Turingmaschine bauen, oder eben nicht. Punkt aus.
^Programmier-
Darf ich mich auch outen? Ich vertrete die These:
«Ein Leben ohne Mops ist möglich aber sinnlos»
womit ich mir einfach Loriot anschließe. :-x
Das muste bei all den Thesen jetzt mal gesagt werden!
SCNR, Ulf
Harald Stowasser
> Am 28.01.2011 19:59, schrieb Harald Stowasser:
>
>> Um das Thema jetzt noch breiter zu treten, oute ich mich als Verteiler
>> der These das es Scriptsprachen eigentlich gar nicht gibt!
>>
>> Eine Sprache kann eine Turingmaschine bauen, oder eben nicht. Punkt aus.
> ^Programmier-
Nur dann ist es auch eine.
> Darf ich mich auch outen? Ich vertrete die These:
> «Ein Leben ohne Mops ist möglich aber sinnlos»
>
> womit ich mir einfach Loriot anschließe. :-x
>
> Das muste bei all den Thesen jetzt mal gesagt werden!
Gilt auch eine Katze, die wie ein Mops aussieht?
Gruß,
Harald
Ulf K@dner
> Am 29.01.2011 11:27, schrieb Ulf K@dner:
>> Darf ich mich auch outen? Ich vertrete die These:
>> «Ein Leben ohne Mops ist möglich aber sinnlos»
>
> Gilt auch eine Katze, die wie ein Mops aussieht?
Sozusagen ein(e) Motz(e). Klar wir wollen nicht zu kleinlich sein. ;-)
Soein Tierchen hatte ich auch mal. Ist aber kurz nachdem Jesus (unser
Mops) bei uns eingezogen ist zum Nachbarn abgewandert. :-(
MfG, Ulf