nicht angemeldet borisbaer
Gunnar Bittersmann
Der Martin
Gunnar Bittersmann
Der Martin
borisbaer
Rolf B
borisbaer
T-Rex
Hallo zusammen,
der PHP-Befehl include erwies sich bisher als wahrer Segen, wenn es darum geht, Websites zu modularisieren. So muss ich nicht mehr auf jeder einzelnen Seite den Code umschreiben, falls ich mal etwas verändern möchte.
Immer wieder habe ich mir jedoch die Frage gestellt, ob diese Handhabung irgendwelche Nachteile mit sich bringt, derer ich mir momentan nicht bewusst bin. Im Moment plane ich, jedes Element, das irgendwie auf Wiederholung angelegt ist, durch durch include einzubinden.
Ist dies sinnvoll? 🤔
Rolf B
@@borisbaer
Im Moment plane ich, jedes Element, das irgendwie auf Wiederholung angelegt ist, durch durch
includeeinzubinden.Ist dies sinnvoll? 🤔
Mir scheint, du willst eher ein Framework verwenden. MVC o.ä.
Ein PHP-Famework oder ein JavaScript-Framework wie Vue auf Node.js.
🖖 Живіть довго і процвітайте
Mir scheint, du willst eher ein Framework verwenden. MVC o.ä.
Ein PHP-Famework oder ein JavaScript-Framework wie Vue auf Node.js.
Hm … das wäre für mich auf jeden Fall Neuland. Was spricht denn dafür?
@@borisbaer
Mir scheint, du willst eher ein Framework verwenden. MVC o.ä.
Ein PHP-Famework oder ein JavaScript-Framework wie Vue auf Node.js.
Hm … das wäre für mich auf jeden Fall Neuland. Was spricht denn dafür?
Dass Dinge wie Modularisierung darin schon gelöst sind.
🖖 Живіть довго і процвітайте
Hallo,
Im Moment plane ich, jedes Element, das irgendwie auf Wiederholung angelegt ist, durch durch
includeeinzubinden.Ist dies sinnvoll? 🤔
frei nach Radio Eriwan: Im Prinzip ja.
Normalerweise sollte und möchte man Code nur einmal schreiben, auch wenn er mehrfach verwendet wird. In Programmiersprachen wäre es ein typisches Beispiel, solchen Code in eine Funktion zu stecken und die Funktion dann von verschiedenen Stellen aus aufzurufen.
Solange es also PHP-Code ist, der innerhalb einer Seite mehrmals genutzt wird, würde ich dir eher zu Funktionen als Mittel der Modularisierung raten. Soll derselbe Code in verschiedenen Seiten genutzt, aber nur einmal gepflegt werden, bieten sich Includes an.
Wenn der includierte Schnipsel selbst kein PHP enthält, sondern nur Markup, CSS und eventuell Javascript, empfiehlt es sich, readfile() anstatt include() zu verwenden. Dann wird die includierte Datei einfach 1:1 an den Client durchgereicht, während include() den Schnipsel immer auch auf PHP-Code untersucht und diesen ausführt.
Einen schönen Tag noch
Martin
@@Der Martin
frei nach Radio Eriwan: Im Prinzip ja.
Aber? 😉
Wenn der includierte Schnipsel selbst kein PHP enthält, sondern nur Markup, CSS und eventuell Javascript, empfiehlt es sich, readfile() anstatt include() zu verwenden.
Im Prinzip ja.
Aber: Sollte sich später ergeben, dass man doch PHP im Include ausführen möchte, muss man für alle Seiten, die das Include einbauen, den Quelltext ändern. Das würde man sich sparen, wenn man gleich include() verwendet.
Das solle man bedenken und abwägen.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
frei nach Radio Eriwan: Im Prinzip ja.
Aber? 😉
aber was ich weiter unten erwähnte: Manchmal möchte man stattdessen einfach nur Code in eine Funktion stecken, anstatt ihn 7mal zu includieren. Oder man möchte readfile() verwenden, weil man nur statisches Markup durchreichen muss.
Aber: Sollte sich später ergeben, dass man doch PHP im Include ausführen möchte, muss man für alle Seiten, die das Include einbauen, den Quelltext ändern. Das würde man sich sparen, wenn man gleich
include()verwendet.Das solle man bedenken und abwägen.
Guter Punkt. Aber bei einer sorgfältig durchdachten Struktur sollte das klar sein, wenn man mit dem Coden beginnt.
Einen schönen Tag noch
Martin
@@Der Martin
Aber: Sollte sich später ergeben, dass man doch PHP im Include ausführen möchte, muss man für alle Seiten, die das Include einbauen, den Quelltext ändern. Das würde man sich sparen, wenn man gleich
include()verwendet.Das solle man bedenken und abwägen.
Guter Punkt. Aber bei einer sorgfältig durchdachten Struktur sollte das klar sein, wenn man mit dem Coden beginnt.
„Sorgfältig durchdacht“ bezieht sich auf die aktuellen Anforderungen? Die können sich aber auch nachträglich ändern.
Beispiel: Man lagert die ganzen link-Elemente für Stylesheet und Favicons (ersteres vorzugsweise im Singular) in ein Include aus und hat dann <?php readfile('includes/style.phtml'); ?> im head zu stehen.
Später fällt einem dann noch ein, am CSS Naked Day das Stylesheet nicht einzubinden – programmatisch, um das nicht jedes Jahr händisch raus- und wieder reinnehmen zu müssen. Und schon hat man PHP im Include, was man bei den ursprünglichen Anforderungen nicht hatte.
🖖 Живіть довго і процвітайте
Aber: Sollte sich später ergeben, dass man doch PHP im Include ausführen möchte, muss man für alle Seiten, die das Include einbauen, den Quelltext ändern. Das würde man sich sparen, wenn man gleich include() verwendet.
Genau so gut kann sich aber herausstellen, dass man auch unter dem Aspekt der Sicherheit besser beim readfile() geblieben wäre. Z.B. weil ein Benutzer der Webseite PHP-Code unterschieben konnte oder weil einem Benutzer PHP-Code untergeschoben wurde… Ich sag mal ganz vorsichtig „Wordpress“ und „Templates“.
Insofern sollte man wohl raten, bloße Daten und Includes schon im Dateisystem sorgfältig zu trennen (Dateiendung reicht nicht…) und mit der zugehörigen, begrenzteren Methode einzubinden.
Solange es also PHP-Code ist, der innerhalb einer Seite mehrmals genutzt wird, würde ich dir eher zu Funktionen als Mittel der Modularisierung raten. Soll derselbe Code in verschiedenen Seiten genutzt, aber nur einmal gepflegt werden, bieten sich Includes an.
Derselbe Code soll in verschiedenen Seiten genutzt werden.
Wenn der includierte Schnipsel selbst kein PHP enthält, sondern nur Markup, CSS und eventuell Javascript, empfiehlt es sich, readfile() anstatt include() zu verwenden. Dann wird die includierte Datei einfach 1:1 an den Client durchgereicht, während include() den Schnipsel immer auch auf PHP-Code untersucht und diesen ausführt.
Danke für den Hinweis! Den Unterschied zwischen inculde() und readfile() kenne ich in Grundzügen. Ich habe (wie Gunnar unten schrieb) für Eventualitäten vorbereitet sein wollen und daher nur include verwendet. In Bezug auf Sicherheitsaspekte habe ich (noch) gar keine Ahnung. Auch ein Grund für die Erstellung dieses Threads – es geht mir ja um mögliche Downsides. Aber eine Frage stellt sich mir doch: Wenn include im Gegensatz zu readfile ein Sicherheitsproblem darstellen könnte, müsste man dann nicht gänzlich darauf verzichten? Wo ist der Unterschied, ob ich einen oder hundert include-Befehle auf einer Seite benutze?
Wo ist der Unterschied, ob ich einen oder hundert include-Befehle auf einer Seite benutze?
Dein schnell laufender, schnell sortierender, aber sonst leider dummer Mitarbeiter (der ist ja nur ein Computerprogramm) kann hundert mal losgehen um einzelne Blätter (kleine Dateien) aus dem Archiv (von der Festplatte, einem Storage) holen (und in ein Fach legen) oder einen ganzen Stapel (große Datei) auf einmal. Holt er den Stapel auf einmal, muss er diesen aber in 100 Blätter zerlegen und diese Blätter dann in die Fächer einlegen.
Was jetzt insgesamt schneller geht ist von einigen Faktoren (Bedingungen) abhängig: Wie lange braucht er um das Zeug zu holen und wie lange um es zu sortieren?
Geheimtipp: Das Archiv ist in den meisten Fällen ziemlich weit weg. Aber da der Mitarbeiter PHP tatsächlich gar nicht selbst ins Archiv geht (Er geht nur bis zu einem anderen Mitarbeiter namens „OS“, der eine Art sehr schnelle Stockwerksbibliothek („Cache“) betreibt und Kopien der von ihm aus dem fernen Archiv geholten Blätter eine Weile dort aufhebt) ergeben sich neue Nebenbedingungen. Und die haben die Eigenschaft, sich aller paar Sekunden zu ändern, was eine Vorhersage schwierig macht. Man könnte allenfalls in eine Statistik schauen um zu wissen zu vermuten, was (wohl, mit welcher Wahrscheinlichkeit) schneller geht und sich Gedanken über den besten (aber vor allem den schlechtesten Fall: keine Datei ist im Cache) machen.
„Worst Case“:
Die Dateien liegen auf einem NAS-Server mit Magnetfestplatten und sind nirgendwo gecacht. Je Datei werden mindestens 50 Millisekunden gebraucht. Bei hundert Dateien also mindestens 5000 Millisekunden oder mindestens 5 Sekunden allein für das Abholen der Dateien.
„Best Case“:
Die Dateien liegen in einem lokalem Cache (RAM). Für jede einzelne Datei wird nur ein Bruchteil einer Millisekunde benötigt. Bei hundert Dateien insgesamt weniger als 1/10 Sekunde.
Hint:
Auf einem hoch belasteten „shared server“ dürfte der “Best Case“ eher selten sein.
Im Moment plane ich, jedes Element, das irgendwie auf Wiederholung angelegt ist, durch durch
includeeinzubinden.Ist dies sinnvoll? 🤔
Durchaus. Allerdings kapselt man wiederholt benötigte Programmteile zunächst in Objekten (nebst Methoden) und Funktionen und diese dann in Libary-Dateien. Den Vorteil der besseren Pflegbarkeit und der wiederholten Nutzung kennst Du ja schon.
Zur Frage der Performance:
Also wenn Du Dateien von Magnetplatten oder NAS-Servern verwendest, keinen Lesecache hast (und die Caches für Bytecode nicht nutzt) dann kann es in Abhängigkeit von der Anzahl der Includes schon langsam werden, weil die Dateien ja zusammengesucht werden müssen. Mit Cache nur beim ersten Mal. Mit modernen Technologien (aktuelle PHP-Versionen, SSDs, Direct Accessed Storages, SAN) verbessert sich das dramatisch. Viele PHP-Skripte haben übrigens eine deutlich längerer Entwicklungspanne als deren Laufzeit jeweils betragen wird…
Natürlich wird ein speziell programmierter Monolith bezüglich der Laufzeit Vorteile haben, das gilt aber nicht allein wegen der Verzögerung beim „Zusammensuchen“ der Dateien, sondern weil in den Funktionen bzw. Methoden bzw. Objekten alle übergebenen Werte als „vergiftet“ betrachtet, ergo sorgfältiger geprüft werden müssen als in einem Programm, bei dem Du weißt, was Du übergibst.
Vorletzte Frage: Was ist denn „excessiv“?
Letzte Frage: Du hast Deine Bibliotheken hoffentlich failsafe und gut isoliert programmiert (weil Du die spätere Datenlage nicht kennst), ordentlich benannt, gut dokumentiert und all das durchsuchbar abgelegt?
Hi,
Viele PHP-Skripte haben übrigens eine deutlich längerer Entwicklungspanne
Hat hier Freud für den Verlust des zweiten s gesorgt? 😉
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
es ist zu einem r mutiert und hat die Panne verlängert.
Den Typo hab ich gar nicht gesehen. Hihi. Steckt aber viel Wahrheit drin - viele viele PHP Scripte kann man als Entwicklungs-Panne klassifizieren. Bis hin zum Code-GAU.
Rolf
Steckt aber viel Wahrheit drin - viele viele PHP Scripte kann man als Entwicklungs-Panne klassifizieren.
Ja. Hab gerade selbst für eine gesorgt. Ein funktionierendes Skript zwecks Performance-Test um
MudGuard$s = microtime( true );
und
echo round( ( microtime( true ) - $s ) * 1000 ) . " Millisekunden" . PHP_EOL;
ergänzt. Sodann, damit das Ergebnis durch die Ausgaben verwässert wird, alle dazwischen vorkommenden echo … durch $s=… ersetzt… und mich gewundert wieso sich PHP denn bitteschön darüber beschwert, dass in der letzten Zeile ein String sei wo doch was numerisches erwartet würde…
(Die Lösung war dann besagtem $s in zwei Zeilen den Name $startTime zu geben.)
Durchaus. Allerdings kapselt man wiederholt benötigte Programmteile zunächst in Objekten (nebst Methoden) und Funktionen und diese dann in Libary-Dateien. Den Vorteil der besseren Pflegbarkeit und der wiederholten Nutzung kennst Du ja schon.
Tut mir leid, könntest du das noch mal für Laien erklären? Was sind Library-Dateien?
Zur Frage der Performance:
Also wenn Du Dateien von Magnetplatten oder NAS-Servern verwendest, keinen Lesecache hast (und die Caches für Bytecode nicht nutzt) dann kann es in Abhängigkeit von der Anzahl der Includes schon langsam werden, weil die Dateien ja zusammengesucht werden müssen. Mit Cache nur beim ersten Mal. Mit modernen Technologien (aktuelle PHP-Versionen, SSDs, Direct Accessed Storages, SAN) verbessert sich das dramatisch. Viele PHP-Skripte haben übrigens eine deutlich längerer Entwicklungspanne als deren Laufzeit jeweils betragen wird…
Ist readfile als Alternative von großem Vorteil, wenn es um die Performance geht? Auf welcher Server-Umgebung die Website dann letztlich landet, ist für mich noch Zukunftsmusik.
Vorletzte Frage: Was ist denn „excessiv“?
Ja, die Formulierung habe ich nachträglich bereut. Also, ich schätze, es würden maximal fünfzig includes pro Seite werden.
Letzte Frage: Du hast Deine Bibliotheken hoffentlich failsafe und gut isoliert programmiert (weil Du die spätere Datenlage nicht kennst), ordentlich benannt, gut dokumentiert und all das durchsuchbar abgelegt?
Ich habe gar keine Bibliotheken programmiert. Es sind ja einfach nur Code-Schnipsel, die sich in einem Ordner befinden, z.B. /inculde/foo.php. Die sind schon geordnet in Unterordnern, aber was du mit Bibliotheken meinst, verstehe ich leider nicht.
Tut mir leid, könntest du das noch mal für Laien erklären? Was sind Library-Dateien?
Die Dateien, welche Du, wie auch immer, womöglich mehrfach, womöglich auch in verschiedenen Projekten includierst.
Ist
readfileals Alternative von großem Vorteil, wenn es um die Performance geht?
Hm. Wie erklärt man das am besten? Wahrscheinlich so, wie ich derlei immer wieder meinen Seminar- oder Kursteilnehmern erkläre...
Stell Dir PHP als Sachberbeiter vor. Der kann entweder
readfile und Geschwister)include und Geschwister)Jetzt überlegen wir mal: Was geht wohl schneller?
Hallo Raketenwilli,
dabei muss man dann aber im Kopf behalten, dass "schneller" nicht immer "besser" ist.
Wie du selbst schriebst - viele kleine readfile sind ineffizienter als ein mittelfetter include, der danach auch noch vorkompiliert im Opcache liegt. Wenn PHP asynchrone reads unterstützen würde, nun ja, dann sähe die Welt vielleicht nochmal anders aus. Tut es aber nicht (es sei denn, man schlägt sich mit der parallel-Lib herum)
Ein superfetter include könnte dagegen zu viel Knorpel enthalten, den man für die aktuelle Seite nicht braucht…
Und sobald das includierte Snippet nicht nur Text ist, sondern auch PHP enthält, ist das Thema readfile eh gestorben.
Rolf
Wenn PHP asynchrone reads unterstützen würde, nun ja, dann sähe die Welt vielleicht nochmal anders aus.
Nun, das klingt wie Kritik an PHP - aber sicherlich nicht nur ich denke, dass es den allermeisten Nutzern von PHP nichts bringt, wenn man es wegen einer überschaubaren Anzahl von Nutzern mit sehr speziellen Wünschen zu einem Monster aufbläst, welches (ähnlich einer teutogermanischen Behörde) viel kann - aber leider zu 90% der Rechenzeit damit beschäftigt ist, sich selbst zu verwalten.
Asynchrones Zeug kann man dort lassen, wo es wirklich gebraucht wird (JS im Browser). Wer Extremes braucht kann sich ja, statt PHP zu benutzen, via CGI am Schatz von C++ und Co. bedienen.
Hallo Raketenwilli,
Nun, das klingt wie Kritik an PHP
Ist Kritik verboten? Macht das PHP unbenutzbar? Ich sage ja nicht, dass man PHP deshalb in die Tonne kloppen sollte. Dafür gäbe es bessere Gründe 😉
Es ist eben etwas, das PHP nicht tut, und deswegen sind viele kleine readfiles ineffizient. Man weiß das, man optimiert im Hinblick darauf, und gut ist.
(JS im Browser)
Jo, da braucht man die eventgetriebene Asynchronität um das GUI nicht festzufressen. Geht aber auch am Server, in node.js. Und in einer async geschriebenen Webmethode in .net auf einem IIS… Oder in Elixier (in Richtung CForum guck)… Das machen gar nicht mal so weniger Runtimes, die in möglichst wenigen Threads möglichst viel erledigen möchten. PHP fing vor Urzeiten nun mal als "Personal Home Page Tools / Forms Interpreter" an und schleppt von diesem Erbe strukturell noch einiges mit, weswegen es sich für hoch belastete Webseiten weniger gut eignet.
Rolf
Hallo borisbaer,
du musst bedenken, dass jeder include mehrere Dinge auslöst:
„Compilieren“ ist je nach PHP Version eine großzügige Bezeichnung, aber auf jeden Fall wird der Quelltext in einen Bytecode umgewandelt, der dann zur Ausführungszeit von der ZEND-Engine interpretiert wird. Neuere PHP Versionen besitzen einen Just-in-Time Compiler, der den Bytecode vor Ausführung in tatsächliche Maschinenbefehle umsetzt.
In wie weit der erzeugte Code tatsächlich kontextabhängig ist, weiß ich nicht. Ich meine damit den Zugriff auf Variablen und Funktionen - man kann einen Namen bei jedem Zugriff durch das Durchsuchen der entsprechenden Verzeichnisse auflösen, oder man tut das einmal bei der Codeumwandlung und speichert die Referenz - aber letzteres setzt eben voraus, dass sich die Umgebung dann nicht mehr ändert. In einer dynamischen Welt wie PHP kann das knifflig sein.
Es kann also sein, dass eine include-Flut kontraproduktiv für die Ausführungsgeschwindigkeit und auch für die Ladezeit des Scripts ist.
Dem entgegen stehen die Caching-Mechanismen von PHP, vor allem der ZEND Opcache. Wenn Du foo.php lädst, wird daraus Bytecode generiert und vom Opcache gespeichert. Wann immer Du foo.php dann nochmal aufrufst, wird geprüft, ob der Bytecode noch im Cache ist und ob der Timestamp von foo.php unverändert ist. Wenn foo.php nun zweiunddrölfzig Includes einbindet, bekommt jedes Include einen eigenen Opcache-Eintrag, und natürlich muss PHP dann für jeden Eintrag vor Verwendung prüfen, ob der Sourcecode nicht erneuert wurde.
Auf einem schwach belasteten Server wird das alles in memory in Caches ablaufen; auf einem schwachbrüstigen Server mit ordentlicher Last kann das dagegen richtig schmerzhaft sein.
Es ist vermutlich hilfreich, die Teile, die Du in includes auslagern willst, zumindest in Gruppen zu ordnen. Jeden Teil, den Du wiederverwenden willst, packst Du in eine Funktion. Und an der Stelle, wo Du den Teil brauchst, rufst Du die Funktion auf.
Mal als ganz dummes Beispiel - das in dieser Form natürlich frei von Nutzen ist:
<?php
// tables.inc
function beginTable() {
?>
<table>
<?php
}
function endTable() {
?>
</table>
<?php
}
function beginRow() {
?>
<tr>
<?php
}
function endRow() {
?>
</tr>
<?php
}
function headCell($content) {
?>
<th><?= htmlspecialchars($content) ?></th>
<?php
function dataCell($content) {
?>
<td><?= htmlspecialchars($content) ?></td>
<?php
}
<?php
include "tables.inc"
beginTable();
for ($i=0; $i<10; $i++)
{
beginRow();
headCell("Zeile $i");
dataCell("foo");
dataCell("bar");
dataCell("baz");
endRow();
}
endTable();
Wie gesagt: in dieser Form sicherlich nicht sehr sinnvoll, es geht nur um's Prinzip.
An Stelle von 5 Includes ist es nur eines, und die Bausteine werden als Funktionen aufgerufen. Selbst wenn ein PHP Script nur die Hälfte der Funktionen in einem solchen Include braucht, ist das auf Grund des Opcache immer noch die bessere Lösung als viele kleinste Dateien.
Solche Funktionen kann man auch als Klassen organisieren, man kann die Struktur des erzeugten HTML auch über Funktionsparameter abbilden, da gibt's 1000 Möglichkeiten, die Dinge zu verkomplizieren (oder eleganter zu machen, je nach Sichtweise).
Meine Meinung, jedenfalls.
Rolf
Auf einem schwach belasteten Server wird das alles in memory in Caches ablaufen; auf einem schwachbrüstigen Server mit ordentlicher Last kann das dagegen richtig schmerzhaft sein.
Ich verstehe, doch welche Alternative habe ich?
Es ist vermutlich hilfreich, die Teile, die Du in includes auslagern willst, zumindest in Gruppen zu ordnen. Jeden Teil, den Du wiederverwenden willst, packst Du in eine Funktion. Und an der Stelle, wo Du den Teil brauchst, rufst Du die Funktion auf.
Das ist sehr interessant. Ich wusste gar nicht, dass das so geht. Kommt das der Ladezeit zugute?
include "tables.inc"
Darf man wirklich diese Endung für solche Dateien verwenden? Ich habe bisher für include() .php genommen und für readfile() .html.
An Stelle von 5 Includes ist es nur eines, und die Bausteine werden als Funktionen aufgerufen. Selbst wenn ein PHP Script nur die Hälfte der Funktionen in einem solchen Include braucht, ist das auf Grund des Opcache immer noch die bessere Lösung als viele kleinste Dateien.
Wie viel besser? 😄
Solche Funktionen kann man auch als Klassen organisieren, man kann die Struktur des erzeugten HTML auch über Funktionsparameter abbilden, da gibt's 1000 Möglichkeiten, die Dinge zu verkomplizieren (oder eleganter zu machen, je nach Sichtweise).
Das kenne ich leider alles nicht! Aber ich mache Fortschritte mit jQuery, Rolf. 😜
@@borisbaer
Aber ich mache Fortschritte mit jQuery, Rolf. 😜
Das ist ein Oxymoron. Den einzigen Fortschritt, den man mit jQuery noch machen kann, ist jQuery nicht mehr zu verwenden.
🖖 Живіть довго і процвітайте
Das ist ein Oxymoron. Den einzigen Fortschritt, den man mit jQuery noch machen kann, ist jQuery nicht mehr zu verwenden.
Sondern Standard-Javascript? Ich google ja im Endeffekt fast alles und jQuery ist einfach an jeder Ecke vertreten. Ob das jetzt gut oder schlecht ist, kann ich nicht beurteilen. Es soll ja, wie ich es verstanden habe, Javascript zusammenfassen und dadurch vereinfachen. Mich dünkt, es ist eher ein philosophischer Disput hier.
@@borisbaer
Das ist ein Oxymoron. Den einzigen Fortschritt, den man mit jQuery noch machen kann, ist jQuery nicht mehr zu verwenden.
Sondern Standard-Javascript? Ich google ja im Endeffekt fast alles und jQuery ist einfach an jeder Ecke vertreten. Ob das jetzt gut oder schlecht ist, kann ich nicht beurteilen. Es soll ja, wie ich es verstanden habe, Javascript zusammenfassen und dadurch vereinfachen.
Nein. jQuery hatte damals mehrere Ziele:
Dafür war jQuery damals gut. Aber damals ist lange vorbei.
Nichts davon ist mehr aktuell:
Die Browserunterschiede gibt es so nicht mehr. Alle Browser verhalten sich i.d.R. standardkonform. Abweichungen gibt es vor allem bei experimentellen Features.
jQuerys Selektor-Engine Sizzle (oder ein Äquivalent) gibt es längst auch in nativem JavaScript (querySelector, querySelectorAll).
Für DOM-Manipulationen gibt es in JavaScript eine Vielzahl an Methoden, die maßgeschneidert das jeweils Gewünschte performant erledigen.
Mit XMLHttpRequest (AJAX) muss man nicht mehr rumhantieren; JavaScript hat das Fetch-API dafür.
Mich dünkt, es ist eher ein philosophischer Disput hier.
Nein. Es sind ganz handfeste Gründe. Für jQuery müssen zig Kilobyte zusätzlicher Code geladen und ausgeführt werden – das kostet Performance.
Der einzige Grund das zu tun wäre, wenn man irgendwelchen Code von anderen verwendet, der auf jQuery basiert. Besser ist, man schaut sich nach einer jQuery-freien Alternative um.
Hinzu kommt noch, dass manche jQuery-Methoden fehlerhaft sind und die jQuery-Entwickler nicht Willens sind, die Fehler zu beheben. Oder nicht einmal das Problem verstehen.
🖖 Живіть довго і процвітайте
Das war aufschlussreich. Nun, ich verstehe deine Punkte.
Ich werde versuchen, meinen Code in Zukunft in Vanilla Javascript umzuschreiben, allerdings muss ich dafür wohl erst mal die ganze Programmiersprache von Grund auf erlernen, sonst wird das nichts. Es ist auf jeden Fall sehr hilfreich, dass man einem hier mit Rat und Tat zur Seite steht.
Mein primäres Ziel war erst mal die Website. Das ist ja mein eigentliches Projekt. HTML, CSS, JS und PHP sind erst mal Mittel zum Zweck, aber im Laufe der Zeit hat sich bei mir schon eine Art Verlangen nach einem besseren Verständnis für die Web-Sprachen entwickelt.
Jedenfalls bleibe ich dran.
Hallo,
Es ist vermutlich hilfreich, die Teile, die Du in includes auslagern willst, zumindest in Gruppen zu ordnen. Jeden Teil, den Du wiederverwenden willst, packst Du in eine Funktion. Und an der Stelle, wo Du den Teil brauchst, rufst Du die Funktion auf.
Das ist sehr interessant. Ich wusste gar nicht, dass das so geht.
ach nein? Das ist dir in den letzten ein, zwei Tagen aber schon mehrfach vorgeschlagen worden. Unter anderem auch von mir.
include "tables.inc"Darf man wirklich diese Endung für solche Dateien verwenden?
Die Dateiendung ist schei... ähm, völlig egal, solange du weißt, was es ist.
Ich habe bisher für
include().php genommen und fürreadfile().html.
Kann man tun, muss man aber nicht.
Aber ich mache Fortschritte mit jQuery, Rolf. 😜
Autsch. Warum tust du dir das an? Bist du masochistisch veranlagt?
Einen schönen Tag noch
Martin
ach nein? Das ist dir in den letzten ein, zwei Tagen aber schon mehrfach vorgeschlagen worden. Unter anderem auch von mir.
Als Funktion einbinden wurde mir vorgeschlagen? Habe ich das überlesen?
Die Dateiendung ist schei... ähm, völlig egal, solange du weißt, was es ist.
Ich verstehe! Ist das mit .inc also nur eine Art Gepflogenheit?
Autsch. Warum tust du dir das an? Bist du masochistisch veranlagt?
Hm, ich bin ja kein Experte, daher bin ich erst mal froh, wenn das, was ich umsetzen möchte, funktioniert.
Hallo borisbaer,
Aber ich mache Fortschritte mit jQuery…
Schön. Technik, die begeistert. Leider Technik von 2010… und Client-Technik. Wir reden hier aber vom Server, und sowas wie pQuery gibt's nicht.
Wie viel besser?
Ich habe keine Ahnung. Aber viele kleine Dateien einzubinden ist definitiv keine gute Idee. Man müsste es auf beide Arten bauen und die Performance messen, bei unterschiedlich belasteten Servern, um eine belastbare Aussage (pun intended 😉) zu bekommen.
Das kenne ich leider alles nicht!
Es ist auch nicht nötig. Es sind Optionen. Je nachdem, wie deine Bausteine aufgebaut sind, kannst Du auch einfach die benötigten Funktionen aufrufen um den entsprechenden Baustein zu generieren. Du kannst die Funktionen auch so schreiben, dass Du entsprechend der Parameter die Generierung der Bausteine variierst, z.B. wenn es darum geht, eine Tabellenzelle mit einer von mehreren möglichen Klassen auszugeben, oder einen Eintrag in der Navigation als Link oder einfach nur als Text, je nachdem, ob dieser Eintrag der aktuellen Seite entspricht oder nicht. Das ist dann auch eine Sache der Planung. Man konzipiert eine Software zumeist top-down, vom allgemeinen zum speziellen, und erzeugt dann zunächst einfache Bausteine, die kleine Teilaufgaben lösen, und verknüpft sie durch höhere Bausteine miteinander, um das Gesamtproblem zu lösen.
Wie es für dich richtig ist, kannst Du letztlich nur selbst herausfinden. Es kann auch sein, dass Du ein paar Runden Try+Error fahren musst.
Rolf
Schön. Technik, die begeistert. Leider Technik von 2010… und Client-Technik. Wir reden hier aber vom Server, und sowas wie pQuery gibt's nicht.
War eigentlich darauf bezogen, dass du mir ja bei den AJAX-Tabs geholfen hast und ich ziemlich planlos war. Ich verstehe das Prinzip nun deutlich besser. Ich muss immer noch viel lernen und PHP will ich mir auch noch genauer anschauen, aber es ist doch ein wichtiger Fortschritt für mich persönlich.
Ich habe keine Ahnung. Aber viele kleine Dateien einzubinden ist definitiv keine gute Idee. Man müsste es auf beide Arten bauen und die Performance messen, bei unterschiedlich belasteten Servern, um eine belastbare Aussage (pon intended 😉) zu bekommen.
Ich werde es bald mal ausprobieren!
Es ist auch nicht nötig. Es sind Optionen. Je nachdem, wie deine Bausteine aufgebaut sind, kannst Du auch einfach die benötigten Funktionen aufrufen um den entsprechenden Baustein zu generieren. Du kannst die Funktionen auch so schreiben, dass Du entsprechend der Parameter die Generierung der Bausteine variierst, z.B. wenn es darum geht, eine Tabellenzelle mit einer von mehreren möglichen Klassen auszugeben, oder einen Eintrag in der Navigation als Link oder einfach nur als Text, je nachdem, ob dieser Eintrag der aktuellen Seite entspricht oder nicht. Das ist dann auch eine Sache der Planung. Man konzipiert eine Software zumeist top-down, vom allgemeinen zum speziellen, und erzeugt dann zunächst einfache Bausteine, die kleine Teilaufgaben lösen, und verknüpft sie durch höhere Bausteine miteinander, um das Gesamtproblem zu lösen.
Ich bemühe mich darum, dies in der Praxis so umzusetzen. Dazu müsste ich allerdings wohl noch deutlich mehr Erfahrung sammeln, vor allem in PHP.
Deine Frage in allen ehren, aber was ist die Alternative? Die Alternative ist doch den kompletten Code in einer Datei zu haben? Bei wirklich kleinen Projekten bzw. bei Testseiten habe ich das in der Tat. Da kann es sein, dass Objekte, Funktionen und Ausgabe in einer Datei stehen. Die Langlebigkeit dieser Projekte ist aber schon im Vorfeld extrem gering. Aber bei echten Projekten?
Selbst bei mir gibt es immer wieder Objekte die wachsen und wachsen. Irgendwann ist die Datei mit ca. 1.000 Zeilen sehr groß und recht schwer zu handeln. Da hilft nur "Teile und Herrsche". Die einzige Möglichkeit das Sinnvoll zu tun ist die Aufteilung in mehrere Objekte und Ausgliederung des Codes in mehrere Dateien. Ich hasse zwar das Wort, aber es ist "Alternativlos".
Wenn du wirklich viele includes hast solltest du eher über die Einbindung der Dateien nachdenken. Ich finde es mühsam in jeder Datei immer die Dinge ein zu binden die man braucht. Ein Autoinclude ist da eine feine Sache.
Gruß includierter T-Rex