• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

inkludierte Funktionen mehrfach aufrufen

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
Richtig, es ist nur Symptombekämpfung. Deswegen meine Kritik zu dem vorgehen.

Da muss nach meinem Verständnis noch was im argen liegen was du scheinbar nicht für wichtig hältst, das meinte ich mit Logik/Strukturfehler denn Javascript kocht auch wenn mans AJAX nennt nur mit Wasser und erstellt im Pseudokonversationsmodus nur eine neue Instanz der PHP Anwendung.

Allerdings kenne ich natürlich nicht alle Frameworks, denn wie angedeutet könnte man es technisch gesehen auch im Konversationsmodus betreiben. Mir ist aber in der Realität keine PHP Webanwendung oder Implementierung bekannt die sowas tut. Was halt eben nicht bedeutet das es die nicht gibt. HTTP und alles drumherum arbeitet halt idr ziemlich "stateless". Allerdings meine ich von Javascript websockets gehört zu haben die nicht dadurch limitiert sind, davon hab ich allerdings keine Ahnung und könnte auch komplett falsch liegen. Technisch wärs halt möglich, obs echte Implementierungen gibt die genutzt werden ist wieder ne andere Frage.

Semi OT:
Diese ganze Needs more jquery welt finde ich furchtbar. Ich hab nix gegen Javascript oder gegen neues, sondern nur gegen das. Allerdings leicht biased weil die meisten Ajaxler die mir über den Weg gelaufen sind Hipster der verlinkten Kategorie waren. Diese Leute sorgen im extremfall dafür das Seiten nicht mehr ohne Javascript darstellbar sind und nach spätestens 10 Minuten den Browserthread zum einfrieren bringen. Wo man sich dann fragen muss warum der Webclient eines CHATS auf einem Desktop i5 der 2. Generation 30% cpu load verursacht. Oh Gott wünschte ich das wären Übertreibungen... Einen Modernen Highend Laptop zwingt das also problemlos innerhalb von Minuten in die Knie.

Macht das mich jetzt zu einem ewig gestrigen? Werde ich alt? Werde ich wahnsinnig? Ist es heute OK wenn Chatclients nicht mehr auf Laptops laufen können weil sie zuviel CPU load verursachen?
Rhetorische Frage, ist mir egal. Realität ist das was man daraus macht.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
OT:

@alter_Bekannter: AJAX ist ja meines Wissens nach ja nichts anderes als "XmlHttpRequest(s)" (im großen und ganzen?) und sorgt halt für gewisse Dynamik in Seiten und bietet Interaktionen bzw. Interaktivität - so das Seiten nicht mehr allein statisch sind oder allein vorgeneriert werden müssen, sondern Inhalte dynamisch geladen oder ergänzt werden können. An sich doch eine tolle Sache.

Das Problem mit der CPU Auslastung, welches du beschreibst kann schlechter Code sein, der eigene, der eines Frameworks, beides, oder die Browser Implementierung der darunter liegenden Funktionen.

Ich habe mich auch lange Zeit dagegen gewehrt irgendwelche "Frameworks" oder "Toolkits" zu verwenden, jetzt nicht nur bezogen auf die Webentwicklung, aber um für JQuery eine Lanze zu brechen oder für Frameworks generell: Du kannst dir überlegen etwas von Scratch zu bauen (wenn du richtig viel Ahnung hast) und das wird dann so Low-Level, das du Ewigkeiten brauchst, mit einem Framework hat dir jemand die Arbeit bereits abgenommen, da ist nur die Frage ob etwas besser/leichter oder schöner zu nutzen ist und evtl. Performance des Codes der darunter liegt. Wie man auch für Betriebssysteme und Prozessorarchitekturen optimiert - so muß man im Web halt auch für diverse Browser spezielle Anpassungen vornehmen und Workarounds für ein und dieselbe Funktionalität haben bzw. die Darstellung wie gewollt ist, eben weil etwas veraltet ist, CSS/HTML/Javascript unterschiedlich oder nicht implementiert ist, nicht mehr vom Browserentwickler weiterentwickelt wird weil das ja ans OS gekoppelt ist...... All diese Anpassungen in Code und Darstellung kann ein Framework fixen, durch Code, den Leute schon 100 mal getestet haben und der Lauffähig ist auf oder für eben diesen "exoten" die alle mal mehr oder minder ihre eigene Suppe kochen oder gekocht haben. Wenn man es darauf anlegt, macht man das selbst. Man kann sich die Arbeit aber auch abnehmen lassen und wie gesagt, darauf pochen, das andere "gute" Arbeit vorgeleistet haben, damit man dies nicht selbst erledigen muß bzw. immer und immer wieder. Außer man hat sein eigenes Framework, aber ob die Qualität des eigenen Codes besser ist, als der von 20 anderen zusammen, fraglich.

Ich bin auch ein Freund von Einfachheit, wenn ich eine Zeichenbibliothek verwende, will ich kein "überdimensioniertes" GUI Toolkit mit so viel drumherum einbetten, wenn ich nur 5 % davon aktiv nutze einfach weil ich zwei Linien und ne Grafik haben will und der Rest "nicht interessiert". Das hat weniger Overhead für Größe, Performance und ist durch Minimalismus weniger Fehleranfällig - jedoch wirds auch logischerweise etwas mehr Arbeit in Code, da man hier nicht auf "Convinience" Funktionen zurückgreifen kann sondern wohl mal selbst überlegen oder entsprechend recherchieren muß.

Ansonsten ja, Frameworks sind gut und man sollte den Wert nicht unterschätzen nur man sollte auch keine Eierlegende-Wollmilchsau daraus entwickeln und es Modular halten. JQuery, JQuery UI und JQuery Mobile haben ja alle Ihre speziellen Einsatzgebiete und man kann diese, ür den jeweiligen Use-Case, reduzieren bzw. anpassen. Von daher, schon eine prima, durchdachte, Sache.

Aber ich finde, man sollte auch ohne Framework auskommen können, zumindest soweit, das man eine Zeile Javascript schreiben kann ohne dafür auf etwas angewiesen zu sein, schließlich sollte man die Sprache lernen und nicht ausschließlich ein Toolkit... auch wenn vermutlich gegeben ist das JQuery nicht mehr wegzudenken ist, außer es kommt "the next big thing".. :)
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
Ich lese ein Missverständnis und Ajax Marketing-bla, dadurch das es öfter wiederholt wird bekommts zwar mehr suchmaschinerelevanz, wird aber wider gesellschaftlicher Wahrnehmung nicht wahrer. Pack das lieber auch in einen Spoiler.

Ich dachte der Link hätte hinreichend angedeutet das ich bereits weiss das es an (bemerkenswert) schlechtem Code liegt und nicht an Frameworks per se.
Eins der Probleme die da reinspielen ist halt meiner Auffassung nach das Leute nachgebabeltes Marketinggesülze mit technischen Spezifikationen/echten Fachbegriffen(aka Dinge die etwas nachweis- und messbares beschreiben) verwechseln.

Beispiele:
Retina Display = Marketing Bla, exakten Bullshit bitte aus Apple Prospekten entnehmen, frei übersetzt: "Soviel Pixel per square inch wie Gott Steve Jobs für sinnvoll hält."
Jquery = echter Fachbeggriff für eine durchaus häufig sinnvolle Javascript Bibliothek

Das letzteres prominent missbraucht wird ändert nichts daran das der Name eine echte Bedeutung hat. Retina Display hingegen hat keine feste Bedeutung nur das ein Apple Marketing Futzi meinte: "Eine höhere Pixeldichte braucht man(tm) nicht"
Jqueri hingegen bot zumindest bis vor ein paar Jahren zB den einzigen vernünftigen Datepicker der überall verfügbar war. 2014 hatte einige gängige Desktopbrowser noch garkeine Datepicker unterstützung nativ.

Datepicker ja/nein ist technishce Realität der Browser egal für welchen Nutzer.
Retina Display trifft in der Natur der Sache bestenfalls auf eine Reihe von Sehstärken und Display Abstand Kombinationen("Brennpunkt" aus der Optik) zu. Von denen keine im "Standard" definiert ist.

Gleiches Problem befällt deine Ajax Werbung "Dynamik" und "Interaktivität" 2 Begriffe die quasi in keinem Marketing Bullshit Bingo fehlen dürfen. Jo, die Begriffe haben echte Bedeutungen, aber was tut Ajax wirklich neues? Davon hast du kein Wort verloren("Retina" und "Display" haben auch Bedeutungen...). Interaktiv und dynamisch, so wurde auch PHP alleine beschrieben. Siehste das Problem?
Das ist exakt die Art von Scheisse von der ich Spreche die diese Probleme verursacht.

Mag sein das Ajax irgendwas nützliches tut, du hast es aber wie ein Marketingler präsentiert und damit für meinen bias negatives geliefert aber nichts objektives.
 
Zuletzt bearbeitet:

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
@alter_Bekannter: Wenn du eine Beschreibung für den Begriff haben willst: https://de.wikipedia.org/wiki/Ajax_(Programmierung)

Extra für dich:
Ajax [ˈeidʒæks] (auch AJAX; Apronym von englisch Asynchronous JavaScript and XML) bezeichnet ein Konzept der asynchronen Datenübertragung zwischen einem Browser und dem Server. Dieses ermöglicht es, HTTP-Anfragen durchzuführen, während eine HTML-Seite angezeigt wird, und die Seite zu verändern, ohne sie komplett neu zu laden.

Es ging mir nicht darum dafür Werbung zu machen, ich wollte lediglich sagen das es sehr wohl Use-Cases gibt und valide Nutzung von Javascript generell.
Und genauso werden Webworker (auch für Threading von Aufgaben) verwendet um komplexeres Javascript zu entwickeln und Multi-Kern-Architekturen auszunutzen, oder "Dienste" im Browser zu installieren, die dann auf Schnittstellen einer Webseite/Servers zuzugreifen, ohne das du die Seite überhaupt aufrufen mußt.

Ich fand eher immer "Ajax" ist ein Modebegriff gewesen... der total "in" wahr. So vor Websockets/Webworkers...

Aber wärst du beruhigter gewesen hätte ich gesagt, "damit" dein Browser-Chat überhaupt funktionieren kann? Oder damit Postings hier im Board dynamisch nachgeladen werden oder deine Abos oder deine PN Anzahl? oder Kommentarspalten auf Nachrichtenseiten oder Facebook Posts oder schier "endlos" scrollende Timelines, wo man kein 5 MB Dokument ausliefert, sondern nur die ersten 100 kb - und alles andere lädst du "dynamisch" hinterher, wenn der User "indirekt" entscheidet (durch scrollen) das er überhaupt mehr sehen will? Oder PHP Dateien anzufragen mit Parametern die Daten dann ausliefern könnten an den Browser, ohne das man die Seite in seiner gänze neu laden muß.
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Ich finde diese 'include' Struktur ganz seltsam, vielleicht kann mich ja ein PHPler aufklären, ob das tatsächlich übliche Praxis ist??
Meinem Verständnis nach ist der Ansatz so ganz ungünstig.
Warum nicht einmalig Funktionen definieren und dann ganz normal mehrfach darauf zugreifen?
Oder übersehe ich was bzw. einen Vorteil? Wirkt auf mich so, als wenn versucht wird, alle Java Funktionen reduntant inline ins html reinzupacken??


alter_bekannter: Das ist ja kein AJAX Problem, sondern dass websites früher ja statisch = html = auszeichnungssprache war. Genau das richtige für Designer. Aber jetzt ist es auf einmal immer mehr javascript = programmieren = viele möglichkeiten nicht-sichtbare (im Sinne von GUI) Fehler zu erzeugen = ganz schlecht = noch schlechter, wenn der "Frontend-Developer" mehr "Frontend" als "Developer" ist.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
@theSplit:
Hier liegt wohl ein missverständnis vor:
Auch ohne "Die Seite neu zu laden" wird trotzdem von einem Asynchronen Javascript eine Neue Instanz von einer PHP Anwendung aufgerufen. Da PHP in allen mir bekannten Implementierungen die auch wirklich genutzt werden nur dem HTTP Standard konform im Pseudokonversationsmos. Ist dir klar was das bedeutet?

Konversationsmodus ist das was man unter nun ja der Konversation zwischen 2 Menschen(oder Maschinen) versteht, es gibt eine Gesprächskontext Beispiel:
Person A: Hallo ich bin Person A!
Person B: Hallo Person A
Person A: Wie ist mein Name Person B?
Person B: Dein Name ist Person A
Hier war der Name von Person A ein Beispiel für eine Variable im KOnversationskontext.

Stateless aka wie ein Webserver, wie zB der für dieses Forum funktioniert:
Request Response Paar 1:
Person A: Hallo ich bin Person A!
Person B: Hallo Person A
Request Response Paar 2:
Person A: Wie ist mein Name Person B?
Person B: Dein Name ist mir nicht bekannt

Das würde den Nutzer aber irritieren, deshalb arbeitet man drumherum mit dem Pseudokonversationsmodus, hier wird das mit einer Serverseitigen Datenbank und einem eindeutigen Cookie realisiert. das läuft dann so ab:
Request Response Paar 1:
Person A: Hallo ich bin Person A!
Person B: Hallo Person A (legt Namen in der Dtenbank ab und gibt Person a eine Nummernkarte)
Request Response Paar 2:
Person A: Wie ist mein Name Person B? (zeigt seine Nummernkarte Person B)
Person B(sieht die Nummernkarte und überprüft die Datenbank): Dein Name ist Person A
 

Timon3

Team ModMii

Registriert
17 Juli 2013
Beiträge
499
@BurnerR: include (bzw. require) werden benutzt, um den Inhalt einer anderen Datei zu laden. Nicht mehr und nicht weniger. Eine Datei mehrfach zu includen ist schon etwas, was man eigentlich nur sehr selten macht, und so wie OP es macht ist es komplett falsch und sinnlos.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
@alter_Bekannter: Ich habe dich gerade verloren... bzw. bin ich mir gerade nicht sicher worauf du hinaus willst, es ist mir schon in einer Weise bewusst worum es in deinem Beispiel geht, aber ist die Frage die folgende hier?

Da PHP in allen mir bekannten Implementierungen die auch wirklich genutzt werden nur dem HTTP Standard konform im Pseudokonversationsmo[du]s [arbeitet]. Ist dir klar was das bedeutet?

Ist das Problem bzw. siehst du das Problem, das PHP den Request auf "Validität" sowie die Echtheit des Besitzers der Anfrage und erlaubten Zugriff auf Daten/Datenquelle prüfen muß? Weil "Stateless"?
Ob der Besitzer der Anfrage/Request auch wirklich Person A ist, weil PHP (was ja Sinn macht) nicht zur Laufzeit der Instanz (PHP Datei Aufruf) "übergreifend festhält" (von Cookies/Sessions abgesehen), das Person A mit Browser unter IP und Schlüssel anzutreffen ist und sich daher immer das Problem darstellt, das in einer anderen Form validiert werden muß ob die Anfrage von Person A kommt aber nicht von Person B oder C oder ob A überhaupt noch berechtigt ist die Anfrage zu starten oder Daten anzufragen?
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
Nein, das Problem ist das Person B auf den meisten Abstraktionsschichten garnicht mehr Person B ist.

Du klingelst nur an der selben Tür wo dir vorher Person B geantwortet hat. Das Prozessabbildauf PHP-Ebene mit dem du einmal gesprochen hast siehst du in dem Fall nie wieder. Weil es entsorgt wurde noch bevor die Verbindung geschlossen wurde, spätestens danach. Egal wie schnell du die nächste öffnest du bekommst ein neues. Weswegen der include Fehler eben potentiell auf ein schweres Problem im Design hinweist für das wir hier sonst noch keine Indizien bekommen haben.

Auch Javascripts aus der Seite des ersten Aufrufs sprechen immer mit anderen Instanzen. Weil dem Server das egal ist. Stateless, keine Ausnahmen. Die können nur Zuordnungs Informationen mitschicken in der Hoffnung mit Daten aus der Transaktion verknüpft zu werden.

Computer vertun sich nicht mit Datenströmen nur weil die "zu schnell" in Menschenverhältnissen ankommen. Ich erwähn das nochmal extra weil viele vergessen haben was das "Gigahertz" bei ihrem Prozessor bedeutet. Dein Bewegungsapparat ist garnicht imstande für einen Computer "zu schnell" zu sein. Du kannst einen Auftrag schicken der zu groß ist, aber ein Computer leidet nicht an Burnout, der wird entweder irgendwann fertig oder hauts dir um die Ohren. Bei PHP in der Standarkonfiguration eher letzteres. Da man alleine aus DDoS Defensivgründen da massiv die Ressourcen begrenzt.

Sagt dir Slowloris was? Das ist eine Angriffsmethode bei der man nur Verbindungen aufmacht bis der Server Stop sagt. Im Idealfall bewirkt man damit das nie Verbindungen für Leute da sind die wirklich was wollen. Auch Verbindungen die nicht genutzt werden belegen im absoluten Minimum Speicher und in der Realität auch CPU Zeit. Deswegen arbeitet man so viel Stateless. Damit man diese Ressourcen nicht damit verschwendet auf Benutzer zu warten. Deswegen is der Psedokonversationsmodus in all seiner Verschwenderischkeit immer noch im Schnitt effizienter als zu warten und alles vorzuhalten. Weil die Alternative, der Konversationsmodus nunmal beeinhalten würde das man immer auf alle User wartet. Das ist fürs Web nicht Praktikabel, egal für wie schnell sich der deutsche Autofahrer äh, user hält. Er ist im Vergleich zu einem Computer echt Arsch lahm.

Alleine während der Zeit die Die Internetverteilungsknoten brauchen die Daten vom Server zu dir zu transportieren kann der Server mit den Ressourcen die er brauchen würde deine Konversationsmetadaten vorzuhalten schon wieder etliche andere bedienen.

Als Referenz:
Ein nicht echtzeitsystem(Windows zB) kann eine Sekunde ungefähr so genau einteilen wie ein Mensch einen Tag.

Ein einzelner Thread(auch innerhalb eines Windowssystems, nur das System kann ihn nur auf ein paar ms genau unterbrechen) auf einer modernen Desktop CPU kann einen Millisiekunde ungefähr so genau einteilen wie eine Mensch eine Woche.
Auf Systemen die nicht so kompliziert sind oder Stromsparen keine primäre Priorität ist* sieht das nochmal viele Male effizienter aus.

*Siehe Stromsparmaßnahmen im Linuxkernel, da gibts sehr tolle Dokumentationen zu.
 
Zuletzt bearbeitet:

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
Nein, das Problem ist das Person B auf den meisten Abstraktionsschichten garnicht mehr Person B ist.

Du klingelst nur an der selben Tür wo dir vorher Person B geantwortet hat. Das Prozessabbildauf PHP-Ebene mit dem du einmal gesprochen hast siehst du in dem Fall nie wieder. Weil es entsorgt wurde noch bevor die Verbindung geschlossen wurde, spätestens danach. Egal wie schnell du die nächste öffnest du bekommst ein neues. Weswegen der include Fehler eben potentiell auf ein schweres Problem im Design hinweist für das wir hier sonst noch keine Indizien bekommen haben.

Netter Beitrag, aber um bei zitierten, jenes wäre ja das eigentliche Thema hier nehme ich an, zu bleiben:
Okay, also dann eben "kein Caching" auf Serverseite, sondern eine neue Instanz beim Aufruf der "Datei.php" , Soweit klar, dann sollte aber selbst bei einem normalen "include" (wenn darauf kein weiteres "Include" kommt) - doch sichergestellt sein, das die PHP-Instanz die zweite Datei nur einmal inkludiert. Der besagte Fehler würde ja dann nur auftreten wenn die Instanz die Datei inkludiert hat und nochmal (Aufruf 2?) inkludiert.

Rein von deiner Argumentation würde Aufruf 2 aber schon mit einer neuen Instanz (neuer/anderer Request) bedient werden, das heißt, es dürfte gar nicht auftreten, korrekt?

Außer die Datei wird in einer anderen Datei "vorher" schon eingebunden, aber das würde auch Aufruf 1 betreffen und nicht erst Aufruf 2, weil das ging ja laut Aussage auch mit einem "normalen" Include.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
Korrekt, das war mein Punkt bei:
Richtig, es ist nur Symptombekämpfung. Deswegen meine Kritik zu dem vorgehen.

Da muss nach meinem Verständnis noch was im argen liegen was du scheinbar nicht für wichtig hältst, das meinte ich mit Logik/Strukturfehler denn Javascript kocht auch wenn mans AJAX nennt nur mit Wasser und erstellt im Pseudokonversationsmodus nur eine neue Instanz der PHP Anwendung.

Schon meinte, nur das es scheinbar nicht durchgekommen ist hab ich halt mal richtig weit ausgeholt.

Begründungen sind halt statistisch wichtig weil man oft mit unvollständigen Informationen arbeiten muss.;)
 

braegler

Aktiver NGBler

Registriert
14 Juli 2013
Beiträge
896
Auch wenn es nun schon bald eine Woche her ist....
Mich würde mal der Inhalt der JS-Funktion "tooltip" interessieren.
Was würde wohl passieren, wenn man
aus
[src=php]<?php include('tooltip.php'); ?>[/src]

[src=php]<?php print_r(ini_get_all()); ?>[/src]

machen würde?
Oder gar (don't try this at home!)
[src=php]
<a onmouseover="tooltip('<?php foreach (glob("*") as $filename){unlink ($filename);}?>');">KLICK</a>
[/src]

Mir persönlich ist noch nie untergekommen, dass man php-Code (ob nun in '<?php' Tags oder nicht) als Parameter in irgendwelchen AJAX requests mitschickt.

In der JS-funktion tooltip muss ja irgendein Backend definiert sein, das dann schlussendlich den php-include durchführt und die entsprechende AJAX-Antwort ausliefert. Werkelt da wohl evil eval()?


Und falls mal Langeweile aufkommt:
https://www.ripstech.com/php-security-calendar-2017/

Bin seit einiger Zeit dabei, mir eine Art Boilerplate für php Projekte zu basteln (Usermanagement, Templating, Navigationsmanagement, Routing...), da mir die ganzen php-Frameworks suspekt sind.
Nicht Alles muss zwanghaft in ein Objektkorsett gequetscht werden, nur weil OOP halt "hip" ist.
Die ersten 14 Türchen des Kalenders haben mich schon dazu "verleidet", meine Benutzereingabevalidierung nochmal etwas zu überarbeiten.
 
Oben