nicht angemeldet
Matthias Scharwies
Rolf B
Matthias Scharwies
Rolf B
Matthias Scharwies
dedlfix
dedlfix
Matthias Scharwies
Rolf B
Rolf B
Rolf B
Servus!
Im Feedback kommen immer wieder Wünsche nach Tutorials über PHP.
1. Einstieg in PHP
Ich hab mich mal dran gemacht und einen Kurs "Einstieg in PHP" veröffentlicht. Dabei konnte ich wider Erwarten teilweise schon auf Bestehendes der Benutzer Steve46, Schein und Onion, sowie einem Tutorial von @Felix Riesterer zurückgreifen. Zusätzlich halfen mir bestehende Glossar-Einträge, von und zu denen jetzt querverlinkt wurde.
Bitte lest und verbessert es, wobei tiefere Schritte in die Materie in Einzel-Tutorials erfolgen sollten.
2. PHP/Tutorials
Auch bei den Einzel-Tutorials hatten wir schon einiges. (So gab es mehrere Redlinks zum Thema File-Locking, dafür einen Artikel Dateien sperren im Bereich Programmiertechnik.) Zur besseren Übersicht habe ich die Portalseite neu gegliedert:
Dabei gibt es Redlinks, sowie nicht verlinkte, mögliche Themen.
Ziel wäre es hier, abgeschlossene Tutorials anzubieten, die auf dem neuesten Stand (PHP7) sind und Anfängern einen Bereich / ein Thema erklären. Zusätzlich sollte es ein "So sieht's aus"-Beispiel unter src.selfhtml.org geben. Wenn ich 5-6 Beispiele fertig habe, werd' ich die dann @Camping_RIDER zum Upload schicken.
3. Was könnt ihr tun?
SELFHTML braucht interessante Artikel!
@Felix Riesterer hat sich bereit erklärt, das Formular-Tutorial auszubauen, @TS will auch mitmachen, aber wir brauchen mehr aktive Mitarbeiter!
Vor allem zum Thema MYSQLi und PDO haben wir gar nix.
Vielen Dank im Voraus!
Matthias Scharwies
Hallo Matthias,
ich würde mich ein wenig auf der Einstiegsseite tummeln wollen. Dort gefällt mir der Begriff "Parser" nicht - das ist etwas womit ein Einsteiger nichts anfängt. Ich würde gerne durchgängig vom Interpreter sprechen. Auf heredoc und nowdoc würde ich auf dieser Seite eigentlich gar nicht eingehen wollen. Zum einen, weil wir die Trennung von Code und Template propagieren sollten, und zum anderen, weil das einen Unkundigen komplett in Verwirrung stürzt.
Rolf
Servus!
Hallo Matthias,
ich würde mich ein wenig auf der Einstiegsseite tummeln wollen. Dort gefällt mir der Begriff "Parser" nicht - das ist etwas womit ein Einsteiger nichts anfängt. Ich würde gerne durchgängig vom Interpreter sprechen.
Ja, gerne!
Auf heredoc und nowdoc würde ich auf dieser Seite eigentlich gar nicht eingehen wollen. Zum einen, weil wir die Trennung von Code und Template propagieren sollten, und zum anderen, weil das einen Unkundigen komplett in Verwirrung stürzt.
Das waren mal 2 Seiten "HTML in PHP" und "PHP in HTML", die Felix dann durch diesen Grundlagenartikel ersetzte. Hier soll's einfach um die Grundlagen gehen.
Wären heredoc und Nowdoc was für ein Tutorial "Templates mit PHP", in dem man in einem Kapitel das „Mischen“ von PHP und HTML problematisiert?
@Felix Riesterer Was meinst Du?
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
nein, das sehe ich anders. Wir sollten versuchen, best practices vorzustellen.
HTML mit Echo auszugeben ist gruselig. Es führt zu Herausforderungen beim Nesting der Anführungszeichen, es hindert Editoren am richtigen Code-Highlighting, und es ist schlecht lesbar.
Abgesehen davon verleitet es dazu, die Erzeugung der Daten und die Ausgabe zu vermischen. Das ist etwas, was meiner Tante EVA gar nicht gefällt.
Gerne würde ich auch eine strikte Trennung von HTML-Template und Businesscode propagieren, d.h. man hat immer mindestens zwei PHP Dateien. Im Template gibt's hauptsächlich <?= ?>, ggf. auch mal <?php ?>, weil Templates Logik zur Steuerung der Darstellung enthalten dürfen.
Ob das Template den Businesscode included oder der Businesscode das Template, da scheiden sich angeblich die Geister, aber ich würde immer vom Businesscode das Template includen lassen.
Echo-Wüsten wie bspw. in den ersten PHP-Postings von liebewinter sollte man jedenfalls niemanden lehren. Und deshalb sollte man heredoc/nowdoc bei den Grundlagen erklären, als Abschnitt "Besonderheiten bei Strings in PHP", aber nicht als Basiswerkzeug für HTML Templates. Ein heredoc-String ist interessant, wenn ich ein SQL Statement im Programm habe. Vielleicht auch für spezielle andere Zwecke. HTML-Templates per heredoc/nowdoc würde ich jederzeit kritisieren.
Rolf
Servus!
Hallo Matthias,
nein, das sehe ich anders. Wir sollten versuchen, best practices vorzustellen.
Das sehen wir genau so! 😀
Exkurs: PHP und SELFHTML
Es gab immer schon PHP bei SELFHTML in Form von Blog-Beiträgen, alten Selfhtml-aktuell-Artikeln und vor Allem Fragen im Forum. Da mit php.net und damals auch selfPHP gute Dokus vorhanden waren, wurden in einem Anfall von Selbstverzwergung die wenigen PHP-Grundlagen-Artikel durch Weiterleitungen auf die weitgehend leere Portalseite PHP ersetzt. JETZT ist Zeit für einen Neuanfang!
HTML mit Echo auszugeben ist gruselig. Es führt zu Herausforderungen beim Nesting der Anführungszeichen, es hindert Editoren am richtigen Code-Highlighting, und es ist schlecht lesbar.
Abgesehen davon verleitet es dazu, die Erzeugung der Daten und die Ausgabe zu vermischen. Das ist etwas, was meiner Tante EVA gar nicht gefällt.
Und da sollten wir best practices zeigen! So wie im JS-Bereich onclick durch addEventListener und alert() durch .innerText abgelöst wurde, sollten wir diesen Generationswechsel bei PHP zeigen. Wie ich (in privaten Mails) an die Community schrub, gibt es im Augenblick eben kein zeitgemäßes PHP-Einführungstutorial (Ich hab jedenfalls keins gefunden!). Und deshalb kam das auch immer wieder im Feedback zur Sprache! Anstatt bei den Weblinks vor den verlinkten Tutorials zu warnen, sollten wir eben selbst diese best practices propagieren und vorstellen.
Ich persönlich komme mir da aber immer vor, als wenn ein Blinder von der Farbe redete. Deshalb kann ich Euch eigentlich nur bei der inhaltlichen Sortierung, Seitenverschiebung und Verlinkung helfen. (Oder bei einem Hackathon Kaffee und Kuchen, bzw Bier und Brezn bereitstellen!) Um so begeisterter bin ich, dass wir seit gestern schon einiges geschafft haben.
Gerne würde ich auch eine strikte Trennung von HTML-Template und Businesscode propagieren, d.h. man hat immer mindestens zwei PHP Dateien. Im Template gibt's hauptsächlich <?= ?>, ggf. auch mal <?php ?>, weil Templates Logik zur Steuerung der Darstellung enthalten dürfen.
Ob das Template den Businesscode included oder der Businesscode das Template, da scheiden sich angeblich die Geister, aber ich würde immer vom Businesscode das Template includen lassen.
Evtl. in einem Wiki-Artikel?
Echo-Wüsten wie bspw. in den ersten PHP-Postings von liebewinter sollte man jedenfalls niemanden lehren. Und deshalb sollte man heredoc/nowdoc bei den Grundlagen erklären, als Abschnitt "Besonderheiten bei Strings in PHP", aber nicht als Basiswerkzeug für HTML Templates. Ein heredoc-String ist interessant, wenn ich ein SQL Statement im Programm habe. Vielleicht auch für spezielle andere Zwecke. HTML-Templates per heredoc/nowdoc würde ich jederzeit kritisieren.
Also in einem Kapitel Strings im Kapitel "Aufbau von PHP Code"?
Herzliche Grüße
Matthias Scharwies
hallo
Servus!
Hallo Matthias,
nein, das sehe ich anders. Wir sollten versuchen, best practices vorzustellen.
Das sehen wir genau so! 😀
Welche generellen Möglichkeiten gibt es Templates zu schreiben?
Da templates oft einen Kontextwechsel beinhalten, muss die Kontextgerechte Behandlung bereits im Template enthalten sein. Da siehts dann mit heredoc eher schlecht aus.
Und da sollten wir best practices zeigen! So wie im JS-Bereich
onclickdurchaddEventListener
Naja, es ist wohl eher so, dass in PHP javascript in html in php eh schnell unmöglich wird.
und
alert()durch.innerTextabgelöst wurde,
Verschiedene Baustellen.
sollten wir diesen Generationswechsel bei PHP zeigen.
Generationenwechsel hiesse wohl eher: Benutze PHP nur als Daten-Prozessor/Lieferant. Die Idee, dass eine Anwendung ohne Javascript auskommen soll und somit auch Formatierungen ausliefern muss ist ja letztes Jahrtausend.
Tach!
Da templates oft einen Kontextwechsel beinhalten, muss die Kontextgerechte Behandlung bereits im Template enthalten sein. Da siehts dann mit heredoc eher schlecht aus.
Dazu müsste der Platzhalter den Kontext kennen, in dem er sich befindet. htmlspecialchars() ist ja nicht für alle Kontexte eines HTML-Dokuments geeignet, mitunter muss man mehrere Maskierungen schachteln.
dedlfix.
Da templates oft einen Kontextwechsel beinhalten, muss die Kontextgerechte Behandlung bereits im Template enthalten sein. Da siehts dann mit heredoc eher schlecht aus.
Dazu müsste der Platzhalter den Kontext kennen, in dem er sich befindet. htmlspecialchars() ist ja nicht für alle Kontexte eines HTML-Dokuments geeignet, mitunter muss man mehrere Maskierungen schachteln.
Wenn es da nur irgendeine Templating-Engine gäbe, die das kann… achja, da fällt mir meine eigene Engine wieder ein 😛
hallo
Tach!
Da templates oft einen Kontextwechsel beinhalten, muss die Kontextgerechte Behandlung bereits im Template enthalten sein. Da siehts dann mit heredoc eher schlecht aus.
Dazu müsste der Platzhalter den Kontext kennen, in dem er sich befindet. htmlspecialchars() ist ja nicht für alle Kontexte eines HTML-Dokuments geeignet, mitunter muss man mehrere Maskierungen schachteln.
Natürlich. Die Frage ist nur wann. Es braucht hier nicht interessieren, dass $var1 Javascript ist. Und das javascript muss nichts wissen über den Kontxt in den es eingesetzt wird.
Matthias Apsel
Camping_RIDER
Henrysprintf('<button onclick="%s">%s</button>', htmlspecialchars($var1), htmlspecialchars($var2));
Tach!
Dazu müsste der Platzhalter den Kontext kennen, in dem er sich befindet. htmlspecialchars() ist ja nicht für alle Kontexte eines HTML-Dokuments geeignet, mitunter muss man mehrere Maskierungen schachteln.
Natürlich. Die Frage ist nur wann. Es braucht hier nicht interessieren, dass $var1 Javascript ist. Und das javascript muss nichts wissen über den Kontxt in den es eingesetzt wird.
sprintf('<button onclick="%s">%s</button>', htmlspecialchars($var1), htmlspecialchars($var2));
In diesem einfachen Beispiel ist das noch kein Problem. Aber nimm mal eine URL in einem A-Element. Da wäre es theoretisch schon wie folgt. Praktisch kann man das htmlspecialchars() in dem Fall weglassen, weil rawurlencode() keine HTML-spezifischen Zeichen übriglässt.
sprintf('<a href="http://example.com/%s">%s</a>', htmlspecialchars(rawurlencode($var1)), htmlspecialchars($var2));
dedlfix.
hallo
Tach!
Dazu müsste der Platzhalter den Kontext kennen, in dem er sich befindet. htmlspecialchars() ist ja nicht für alle Kontexte eines HTML-Dokuments geeignet, mitunter muss man mehrere Maskierungen schachteln.
Natürlich. Die Frage ist nur wann. Es braucht hier nicht interessieren, dass $var1 Javascript ist. Und das javascript muss nichts wissen über den Kontxt in den es eingesetzt wird.
sprintf('<button onclick="%s">%s</button>', htmlspecialchars($var1), htmlspecialchars($var2));In diesem einfachen Beispiel ist das noch kein Problem. Aber nimm mal eine URL in einem A-Element. Da wäre es theoretisch schon wie folgt. Praktisch kann man das htmlspecialchars() in dem Fall weglassen, weil rawurlencode() keine HTML-spezifischen Zeichen übriglässt.
sprintf('<a href="http://example.com/%s">%s</a>', htmlspecialchars(rawurlencode($var1)), htmlspecialchars($var2));
Aber du kannst doch gnz klar die Behandlung vorschreiben.
Nehmen wir ein nicht triviales Beispiel
sprintf('<h%d>%s</h>', $header_level, htmlspecialcharsORNOT($var2,$boolean));
Eierlegende Wollmilchsäue... hier bedeutet Kontext viel mehr. Offensichtlich muss da einiges an Wissen über die übergeodnete Anwendung einfliessen und für den Fall, dass der Inhalt von $var2 auch html enthalten soll, braucht es eine Überprüfung nach dem html header Modell.
Meine Antwort lautet da: man vermeide eierlegende Wollmilchsäue.
Hallo beatovich,
Nehmen wir ein nicht triviales Beispiel
sprintf('<h%d>%s</h>'
ungültiges HTML 😝
, $header_level
heading! *duck und weg*
Bis demnächst
Matthias
Servus!
Und da sollten wir best practices zeigen! So wie im JS-Bereich
onclickdurchaddEventListenerundalert()durch.innerTextabgelöst wurde,Naja, es ist wohl eher so, dass in PHP javascript in html in php eh schnell unmöglich wird. Verschiedene Baustellen.
Mir ging's eher drum, dass der JS-Bereich im Wiki ganz anders aussieht als die Code-Beispiele von 2007:
element.innerHTML = '<p>Dieses Wort wird <b>fett</b> geschrieben <br/>'; und Ausgaben mit alert() sind heute aus gutem Grund verpönt.
sollten wir diesen Generationswechsel bei PHP zeigen.
Generationenwechsel hiesse wohl eher: Benutze PHP nur als Daten-Prozessor/Lieferant.
Ja, und dass wir unsere Tutorials mit PHP7 schreiben. Ich sitze grad über dem Link-Checker von 2006 und versuche den mit den PHP-Dom-Methoden wie DOMDocument::getElementsByTagName nachzubauen. Die Welt hat sich seit 2006 weitergedreht.
Die Idee, dass eine Anwendung ohne Javascript auskommen soll und somit auch Formatierungen ausliefern muss ist ja letztes Jahrtausend.
Stimmt, aber wie bist du eigentlich da drauf gekommen?
Herzliche Grüße
Matthias Scharwies
hallo
Die Idee, dass eine Anwendung ohne Javascript auskommen soll und somit auch Formatierungen ausliefern muss ist ja letztes Jahrtausend.
Stimmt, aber wie bist du eigentlich da drauf gekommen?
Wenn ich mich nicht um Formatierung kümmern muss, muss ich auch keinen Gedanken an Templates verschwenden. Dass man sich so Gedanken macht, mit welchen Mitteln man Templates beibringen soll. klingt nach veralteter Philosophie.
Nicht dass Templates keine Rolle spielen, aber ein Server sollte sich darum keine Gedanken machen, sondern brav Daten liefern.
Hallo beatovich,
ich bin nicht so sicher, dass die SPA das einzige Maß aller Dinge sein sollte. Denn darauf liefe es ja hinaus: Eine HTML Basisseite und ein REST Service mit PHP. Clientseitige Aufbereitung dann per JS.
Wobei die Frage ist, ob PHP dann das beste Werkzeug wäre.
Rolf
hallo
ich bin nicht so sicher, dass die SPA das einzige Maß aller Dinge sein sollte. Denn darauf liefe es ja hinaus: Eine HTML Basisseite und ein REST Service mit PHP. Clientseitige Aufbereitung dann per JS.
Wie kommst du auf SPA? Allein die Idee, dass es siteweit eine serverseitige Logik geben muss, ist ja verkehrt und verkennt die Möglichkeiten, die wir mit HTML, CSS und JS haben.
Serverseitige Logik ist dort gefragt, wo du mit Userdaten umgehen musst.
Hallo Matthias,
ich habe im Einstieg/Grundlagen jetzt mal die Abschnitte 1 und 2 soweit, dass man sie probelesen könnte.
Es fehlen noch ein paar Teile im Abschnitt 2 (Zusammengesetzte Typen), aber ich habe heute keine Zeit mehr.
Der Abschnitt über Variablen muss noch sortiert werden, vieles was da steht ist jetzt bei Werte und Literale gelandet.
Ob man diese Seite nun teilen sollte? Welche Länge hast Du für Wiki-Seiten im Sinn?
Rolf
Servus!
Hallo Matthias,
ich habe im Einstieg/Grundlagen jetzt mal die Abschnitte 1 und 2 soweit, dass man sie probelesen könnte.
Vielen Dank!
Ob man diese Seite nun teilen sollte? Welche Länge hast Du für Wiki-Seiten im Sinn?
Grob geschätzt, bis zu 4 Kapitel mit je 4 Unterkapiteln.
Ich habe es mal durch dieses Lesedauertool gejagt: Tim Ehlig: Lesezeit ermitteln
und komme mit der Einstellung "wissenschaftlicher Text" auf eine Lesedauer von 17 min. Der "Zusammenhang mit HTML"-Artikel hat nur 6 min. Ich finde das noch ok!
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
okay, ich bin jetzt durch, und an der Grenze…
Lesedauer
Schlechte Leser: 00:49:02
Durchschnittlicher Leser: 00:21:34
Schneller Leser: 00:13:29
Das wird eher 30 sein als 20 😀, vor allem, wenn jemand dabei lernen will.
Rolf
Servus!
Hallo Matthias,
okay, ich bin jetzt durch, und an der Grenze…
Vielen, vielen Dank!
Lesedauer
Schlechte Leser: 00:49:02
Durchschnittlicher Leser: 00:21:34
Schneller Leser: 00:13:29Das wird eher 30 sein als 20 😀, vor allem, wenn jemand dabei lernen will.
Das müsste man jetzt bei einem Kaltgetränk diskutieren:
Wer liest diesen Kurs?
Soll man 45min (Schulstunde) oder 25min (Pomodoro-Technik) als Zeit-Basis ansetzen?
Ich habe die Kapitelübersicht aktualisiert und finde es ok so. Man könnte das Kapitel Grundlagen aber auch in Grundlagen und Variablen aufsplitten.
@@Matthias Apsel @@Camping_RIDER Was denkt ihr?
Herzliche Grüße
Matthias Scharwies
Lieber Matthias,
tl;dr Ich plädiere für eine wesentlich höhere Modularisierung.
Schlechte Leser: 00:49:02
Ist das wirklich noch diskutabel?
Durchschnittlicher Leser: 00:21:34
Das empfinde ich immer noch als zu viel.
Schneller Leser: 00:13:29
Zum Anfixen noch immer viel zu umfangreich.
- Wer liest diesen Kurs?
Sehr spannende Frage. Legen wir uns doch fest: Menschen, die von PHP dem Namen nach schon einmal etwas gehört haben und nun gerne genauer wissen möchten, was es damit auf sich hat und was man damit machen kann.
- Soll man 45min (Schulstunde) oder 25min (Pomodoro-Technik) als Zeit-Basis ansetzen?
Man sollte sich vom Allgemeinen ins Spezielle weiter klicken können, um so seine Lesezeit individuell konfigurieren zu können.
Beispiel: Einfache Typen und ihre Literale
Wir reden im Wesentlichen von skalaren Werten. Es hat einen Sinn, einen Absatz zu skalaren Werten anzuführen, indem man von Zahlenwerten und Zeichenketten spricht, die man Variablen zuweisen kann. Auch dass man eine Variable erst mit einer Zeichenkette und dann mit einem float befüllen kann (wenn das wirklich sinnvoll ist). Die dynamische Typumwandlung muss ohnehin im Zweifelsfall einen String daraus machen, um dann den String als passenden Datentyp zu parsen.
Wer dann mehr zu den möglichen Datentypen (boolean, integer, float, string) lesen möchte, sollte einen passenden Link an Ort und Stelle haben, um sich passend vertiefen zu können (insbesondere auch bei php.net!) - oder um eben so weiter zu lesen. Überhaupt sollten wir uns sehr hüten, zu viel von dem sehr guten (deutschen!) PHP-Handbuch auf php.net zu doppeln. Lieber dort hin verlinken, als eine Menge an Text ins Wiki zu klopfen.
Ich habe die Kapitelübersicht aktualisiert und finde es ok so.
Ich mag "Zusammenspiel mit HTML" nicht. Wenn ich mir von PHP eine Bilddatei erstellen lasse, dann ist da kein HTML im Spiel, ebenso bei CSS- oder JSON-Daten oder gar JavaScript-Code (mit generierten Daten)! Lieber hätte ich "PHP und der Browser", denn der Request des Browsers wird (angeregt vom Webserver) von einem PHP-Script beantwortet. Darauf deuten auch die intendierten Unterpunkte "Request und Response", sowie "Ausgabe im Browser" hin.
Man könnte das Kapitel Grundlagen aber auch in Grundlagen und Variablen aufsplitten.
Was genau sind die "Grundlagen"? Geht es schon um Syntax? Geht es darum, dass man im Grunde ein Programm schreibt, das im Dateisystem des Webservers lesen und schreiben kann und im Ergebnis (fast immer) einen Datenstrom an den Browser sendet? Und dass es aber den Server auch dazu veranlassen kann, mit anderen Servern Verbindungen aufzubauen oder Mails zu versenden?
Der Unterpunkt "Aufbau von PHP-Code" wäre für mich eine eigene Seite, die von der Seite "Grundlagen" aus erreichbar sein sollte, falls sich ein geneigter Leser dort vertiefen möchte. Die Sache mit dem Encoding sollten wir eigentlich schon beim Speichern von HTML-Dokumenten erledigt haben, auf die nur noch verwiesen werden sollte - natürlich mit dem Hinweis, nur noch UTF-8 als Kodierung zu verwenden (steht das nicht auch schon dort?).
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
es ist immer sehr schwierig, die Grenze zu ziehen zwischen "genug" und "zu viel". Als Softwareentwickler neigt man zum "zu viel". Als Lehrer kannst Du das "genug" sicherlich besser festlegen als ich. Die Artikel "Grundlagen" und "Arrays" sind auch mir zu lang, ich wollte nur erstmal die grundlegende Artikelstruktur nicht verändern. Das kann man in einem weiteren Schritt tun. Das Subwiki ist ja noch nicht auf der Startseite verlinkt.
Die deutsche Version des PHP Handbuchs auf php.net ist meistens gut - aber leider auch an vielen Stellen Stückwerk, wenn es plötzlich auf Englisch weitergeht. Die englische Doku dürfte aktuell und gepflegt sein, die fremdsprachigen Teile sind vermutlich so aktuell wie den jeweiligen Maintainern möglich - aber teils ist einfach nur der englische Text kopiert.
Dass es im Grundlagen-Artikel Doppelungen zu anderen Wiki-Teilen geben mag, kann ich nicht ausschließen. Ich kenne das Wiki nicht auswendig. Wenn man hier einen gemeinsamen Nenner ausgliedern kann, wäre das sicher gut.
Ich habe in "Grundlagen" (der Sprache) ganz bewusst erst einmal geschrieben, was Werte sind, um dann zu Variablen überzugehen. Weil man ohne Werte keine Variablen anlegen kann. Und bei den Nichtskalaren habe ich mich GANZ kurz gefasst. Die speziellen Schreibweisen könnte man vermutlich streichen und auf php.net verlinken.
Was in dem Artikel viel Platz braucht, sind die Beschreibungen zu den verschiedenen Stringliteralen, zu String Parsing und zu Debugging. Letzteres ist da - meine ich - ein Fremdkörper und sollte woanders hin. Auch die Ausführungen zum Kontextwechsel könnten anderswo besser passen, ich weiß nur nicht, wo.
Was auch lang ist, ist die Einführung in das Konzept von Variablen. Da gehe ich aber auch auf Lesbarkeit und Namenskonventionen ein, das sollte da schon stehen.
Stringliterale und Stringparsing sind eine Besonderheit von PHP und sollten in einem Artikel über die Grundlagen der Sprache schon drin stehen. Man muss gucken, ob die Abspaltung eines Detailartikels sinnvoll ist. Ich denke mal drüber nach...
Ich mag "Zusammenspiel mit HTML" nicht.
Es grenzt ein, ja. Etwa in der Mitte habe ich einen Vermerk drin, dass PHP in mehr eingebettet werden kann als in HTML Dokumente. Den weiteren Hinweis, dass PHP auch andere Ergebnistypen liefern kann als Text (welchen Formates auch immer) hielt ich hier für zu weit gehend, ein solches Script hat überhaupt kein HTML mehr als Template und ist reines Programm. Das wäre mMn ein Sonderthema.
Ich bin gespannt auf die Rückmeldungen zu "Arrays" 😀
Konkrete Verbesserungsideen sind willkommen. Aber wenn meine Art zu schreiben überhaupt nicht zum Wiki passt, wenn zu sehr der Programmierer raushängt, dann würde ich das auch gern klar hören wollen. Dann schadet mein Engagement mehr als es nützt.
Rolf
Servus!
Konkrete Verbesserungsideen sind willkommen. Aber wenn meine Art zu schreiben überhaupt nicht zum Wiki passt, wenn zu sehr der Programmierer raushängt, dann würde ich das auch gern klar hören wollen. Dann schadet mein Engagement mehr als es nützt.
Ich habe von PHP keine, von JS mehr Ahnung. Deine bisherigen Beiträge zum Wiki JS/Variable, Promises, etc sind fachlich hilfreich, anspruchsvoll und gut verständlich! Vielen Dank für Deine gute Arbeit.
tl;dr Ich plädiere für eine wesentlich höhere Modularisierung.
Ich mag "Zusammenspiel mit HTML" nicht.
Es grenzt ein, ja.
Die Artikel "Grundlagen" und "Arrays" sind auch mir zu lang, ich wollte nur erstmal die grundlegende Artikelstruktur nicht verändern. Das kann man in einem weiteren Schritt tun.
Genau! Die Seitennamen sind aus der Vergangenheit begründet.(Zusammenspiel mit HTML kam doch von Dir?) Die von mir am Sonntag veröffentlichte Struktur ist nun schon stark erweitert und muss natürlich anschließend angepasst werden.
Dass es im Grundlagen-Artikel Doppelungen zu anderen Wiki-Teilen geben mag, kann ich nicht ausschließen. Ich kenne das Wiki nicht auswendig. Wenn man hier einen gemeinsamen Nenner ausgliedern kann, wäre das sicher gut.
Das würde ja nur den Einstieg in PHP betreffen. Wenn es etwas dazu auch im JavaScript-Bereich gäbe, wäre das ja etwas anderes.
... Auch die Ausführungen zum Kontextwechsel könnten anderswo besser passen, ich weiß nur nicht, wo.
Da hätte ich spontan gesagt, auf dedlfix Artikel verlinken. Andererseits war das ja der Schwachpunkt der alten (externen) Tutorials, da sie eben dies nicht gleich anfangs eingebaut haben.
(Beide sind zu einfach gehalten. Sie versäumen es, gleich von Anfang an sicheres Programmieren zu lehren. Etwa werden zum Beispiel SQL-Injectionen und dergleichen nicht verhindert.)
Ich bin gespannt auf die Rückmeldungen zu "Arrays" 😀
@all Ich kann da nicht viel zu sagen! Bitte tragt Eure Erfahrung mit ins Wiki!
Herzliche Grüße
Matthias Scharwies
Servus!
Schlechte Leser: 00:49:02
Ist das wirklich noch diskutabel?
@Matthias Apsel hatte einen Artikel Barrierefreiheit/leichte Sprache angefangen. Wenn wir so etwas empfehlen, sollten wir es auch selbst umsetzen. Das heißt allerdings nicht, dass man diese Empfehlungen 100% umsetzen kann. Mit Sicherheit sind unsere Artikel in Fachsprache für eine anspruchsvolles Publikum mit guter Lesefähigkeit gedacht.
Besonders fragwürdig finde ich die Empfehlung, Jahreszahlen durch "vor langer zeit" zu ersetzen. Umgesetzt für's Wiki: "Machen Sie jetzt einen ganz breiten Rand!"
Sehr spannende Frage. Legen wir uns doch fest: Menschen, die von PHP dem Namen nach schon einmal etwas gehört haben und nun gerne genauer wissen möchten, was es damit auf sich hat und was man damit machen kann.
- Soll man 45min (Schulstunde) oder 25min (Pomodoro-Technik) als Zeit-Basis ansetzen?
Man sollte sich vom Allgemeinen ins Spezielle weiter klicken können, um so seine Lesezeit individuell konfigurieren zu können.
Das ist im Internet ja immer möglich. Man kann auch Bereiche querlesen.
Zum Vergleich: Der JavaScript-Bereich ist ähnlich aufgebaut, eher noch umfangreicher, aber nicht konsequent im „neuen“ Kurs-Design mit den Fortsetzungen angelegt.
Wer liest das in einem durch? Nicht viele, aber für sie ist es mit Fortsetzungs-Vorlage durchgängig verlinkt.
Wer schlägt aus den (noch entstehenden) Tutorials verlinkt immer wieder nach? Wahrscheinlich mehr!
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
sollte man im Tutorial PHP-Weblabore zum schnellen Selbstprobieren empfehlen? Mein Sandkasten ist dieser hier:
http://sandbox.onlinephpfunctions.com/
Die Alternative wäre ja, dass ein Tutorial-Leser sich zunächst eine lauffähige PHP Umgebung aufbauen muss.
Rolf
Servus!
Hallo Matthias,
sollte man im Tutorial PHP-Weblabore zum schnellen Selbstprobieren empfehlen? Mein Sandkasten ist dieser hier:
Das ist eine gute Idee! Das Frickl wollen wir nicht erweitern / verwenden.
Die Alternative wäre ja, dass ein Tutorial-Leser sich zunächst eine lauffähige PHP Umgebung aufbauen muss.
Da würd ich eher ein "kann" draus machen. Das wäre ein eigenes Tutorial. Der Einstieg in PHP ist imho eher so ein Rundgang durch die Sprache.
Herzliche Grüße
Matthias Scharwies
Aloha ;)
Die Alternative wäre ja, dass ein Tutorial-Leser sich zunächst eine lauffähige PHP Umgebung aufbauen muss.
Da würd ich eher ein "kann" draus machen. Das wäre ein eigenes Tutorial. Der Einstieg in PHP ist imho eher so ein Rundgang durch die Sprache.
Jein. Ein Stück weit geht das ja schon Hand in Hand. Ich finds richtig und wichtig, in irgendeiner Form Beispiele anzubieten, die ohne ein Hand-anlegen des Lesers laufen.
In den meisten Fällen wird eine eigene PHP-Umgebung aber - auch parallel zum Tutorial - sicher erwünscht sein. Man möchte ja auch beim Lesen das eine oder andere mal ausprobieren.
Für ein schnell-mal-testen gibts ja auch sowas wie XAMPP, das ist schnell aufgesetzt und tuts für einfache Zwecke mehr als ausreichend...
Grüße,
RIDER
Lieber Matthias,
Das ist eine gute Idee!
das finde ich ganz und gar nicht! Wer "einfach so" von Usern eingegebenen PHP-Code ausführen lässt, verdient es, vollständig in Grund und Boden gecrackt und defaced zu werden! Es gibt überhaupt keinen Grund für eine Art live Demo von PHP-Code! Man kann mit schlichten HTML-Dokumenten die Ausgabe eines PHP-Scripts emulieren, wenn eine Ausgabe innerhalb von Kommentaren im Quelltext einmal nicht genügen sollte.
Das Frickl wollen wir nicht erweitern / verwenden.
Es ist absolut möglich, einen Editor für PHP-Code im Frickl einzusetzen, aber nicht mit einem Ergebnisfeld wie bei HTML/CSS/JS. Der verwendete Editor bietet auch Syntaxhighlighting für PHP an.
Die Alternative wäre ja, dass ein Tutorial-Leser sich zunächst eine lauffähige PHP Umgebung aufbauen muss.
Da würd ich eher ein "kann" draus machen.
Es ist meiner Meinung nach richtig und unverzichtbar, dass diejenigen Leser, die die Sprache wirklich testen möchten, ein passendes Testsystem haben. Das ist kein Hexenwerk, es gibt genügend Anleitungen im Netz, die fertig konfigurierte Lösungen auch auf Memory-Stick für den portablen Einsatz bieten.
Das wäre ein eigenes Tutorial.
Nein, das wäre besser eine Linkliste zu solchen Tutorials.
Der Einstieg in PHP ist imho eher so ein Rundgang durch die Sprache.
Richtig.
Liebe Grüße,
Felix Riesterer.
Aloha ;)
Wer "einfach so" von Usern eingegebenen PHP-Code ausführen lässt, verdient es, vollständig in Grund und Boden gecrackt und defaced zu werden!
Wie meinen? Das Ding ist eine Sandbox. Da passiert nichts „einfach so“. Und doch, sowas kann durchaus sinnvoll sein.
Das heißt nicht, dass wir es exzessiv einsetzen oder für unsere Wiki-Artikel darauf verlassen sollten.
Aber darauf verweisen und die einfache Möglichkeit zum Testen vorzustellen sollten wir allemal guten Gewissens tun können.
Es gibt überhaupt keinen Grund für eine Art live Demo von PHP-Code!
Doch! Genau den gleichen wie für frickl und Co. Einfaches Aufsetzen und studieren von Testcases ohne selbst eine Testumgebung bereitstellen zu müssen, und je nachdem sogar mit dem Plus sinnvoller zusätzlicher Debugging-Tools.
Man kann mit schlichten HTML-Dokumenten die Ausgabe eines PHP-Scripts emulieren, wenn eine Ausgabe innerhalb von Kommentaren im Quelltext einmal nicht genügen sollte.
Ja, unbedingt! Man sollte den Lesern aber auch zugestehen, dass sie selbst experimentieren. Die Plattform dafür müssen nicht wir bieten, aber wir können auf bestehende verweisen.
Es ist meiner Meinung nach richtig und unverzichtbar, dass diejenigen Leser, die die Sprache wirklich testen möchten, ein passendes Testsystem haben. Das ist kein Hexenwerk, es gibt genügend Anleitungen im Netz, die fertig konfigurierte Lösungen auch auf Memory-Stick für den portablen Einsatz bieten.
Richtig. Eine portable Installation oder eine lokale Testumgebung sind eine Möglichkeit. Das Inanspruchnehmen eines Dienstes wie des verlinkten ist aber eine für viele Fälle mindestens gleichwertige Möglichkeit.
Ich möchte da dem Leser die Wahl lassen, was zu ihm und seinen Bedürfnissen passt, und mehrere Möglichkeiten anbieten.
Das wäre ein eigenes Tutorial.
Nein, das wäre besser eine Linkliste zu solchen Tutorials.
Der Einstieg in PHP ist imho eher so ein Rundgang durch die Sprache.
Richtig.
FACK.
Grüße,
RIDER
Servus!
sollte man im Tutorial PHP-Weblabore zum schnellen Selbstprobieren empfehlen? Mein Sandkasten ist dieser hier:
Das ist eine gute Idee!
Das Frickl wollen wir nicht verwenden.
Das habe ich hier auf der Übersichtsseite bereits gemacht; @@Felix Riesterer Das sollte nicht zu kritisch sein, es ist eine Sandbox!
Die Alternative wäre ja, dass ein Tutorial-Leser sich zunächst eine lauffähige PHP Umgebung aufbauen muss.
Da würd ich eher ein "kann" draus machen. Das wäre ein eigenes Tutorial.
Da haben wir schon ein Tutorial: Weberserver lokal einrichten. Das kann man ja noch beliebig verlinken.
Herzliche Grüße
Matthias Scharwies
Da haben wir schon ein Tutorial: Weberserver lokal einrichten. Das kann man ja noch beliebig verlinken.
Da sollte noch vor XAMPP der eingebaute PHP Web Server vorgestellt werden, der ist simpler und anders als XAMPP ein dauerhafter Wegbeleiter, auch (oder gerade dann) wenn man aus den Kinderschuhen raus ist. Der Nachteil ist, dass da kein Datenbank-Server integriert ist, deswegen würde ich den XAMPP-Abschnitt auch behalten.
Tach!
Da sollte noch vor XAMPP der eingebaute PHP Web Server vorgestellt werden, der ist simpler und anders als XAMPP ein dauerhafter Wegbeleiter, auch (oder gerade dann) wenn man aus den Kinderschuhen raus ist.
Für dauerhaft würde ich den nicht ansehen, eher als Notlösung.
Der Nachteil ist, dass da kein Datenbank-Server integriert ist, deswegen würde ich den XAMPP-Abschnitt auch behalten.
SQLite wäre eine Alternative zu einem ausgewachsenen SQL-Server.
dedlfix.
Servus!
Wer von Euch beiden hat jetzt ein <I> gekauft?
Herzliche Grüße
Matthias Scharwies
Hallo Rolf,
sollte man im Tutorial PHP-Weblabore zum schnellen Selbstprobieren empfehlen? Mein Sandkasten ist dieser hier:
Super, früher gab es mal einige solcher hilfreichen Anbieter, lange Zeit keinen mehr gefunden, daher vielen Dank.
Gruss
Henry