PHP UG Munich in München

Hallo PHPUG München,

Nach längerer Abwesenheit hier wieder ein kurzer Artikel von mir. Ich weiß nicht, ob nur ich bislang so unwissend war, aber vielleicht geht es euch ja wie mir...

Ich arbeite in meinen Projekten eigentlich durchgängig mit UTF-8 Kodierung. Fragt mich nicht warum, hab irgendwann damit angefangen (sicher mit gutem Grund), in der Zwischenzeit ist das Standard bei mir.

Letztens hatte ich aber ein eigentümliches Problem: wenn in einem String, den ich mit wordwrap fix umbreche (also auch innerhalb von strings, zusatzparameter "cut" auf true setze), an der Umbruchstelle ein Sonderzeichen stand (z.b. doppelte Anführungszeichen), dann wurde aus diesem einen Zeichen auf einmal 3 oder sogar 4. Es sieht so aus, als ob wordwrap nicht vorher bzw. nachher umbricht, sondern irgendwie IM Sonderzeichen und es zerreißt. Dass die inneren Quarks des Sonderzeichen-Atoms natürlich hässlich waren (und teilweise weitere Probleme verursachten) versteht sich von selbst.

Das Spannende dran: in meinen Tests konnte ich das jederzeit reproduzieren, aber nur, wenn ich das Zeichen selbst in den Quellcode geschrieben habe. Wenn ich das Zeichen über dessen ASCII-Code von PHP erzeugen lasse, war alles ok. Straaange...

Ich hab lange Zeit nichts darüber gefunden (vielleicht suche ich falsch?)und diese Funktion dann schließlich in JavaScript geschrieben, da die ganze Sache einfach zu unsicher war.

Letzte Woche hatte ich nun Gelegenheit, bei Mayflower mit zwei Experten zu sprechen und siehe da, die Lösung ist ganz einfach: wordwrap ist einfach nicht "utf-8 safe". Ihr hört richtig: man kann bzw. sollte keine utf-8 kodierten Strings mit wordwrap verarbeiten. Zusätzlich zu diesem Sonderzeichen-Bug erkennt wordwrap wohl auch die Länge des Strings nicht immer korrekt (utf-8 zeichen brauchen mehr Byte), es kann also auch hier zu Fehlern kommen.

Da es bislang noch keine utf-8 safe Variante gibt, bleibt euch wie mir nur übrig, entweder eine Alternative in PHP selbst zu schreiben (bzw. das Netz danach abzusuchen) oder das Thema z.b. JavaScript zu überlassen (was aber z.B. bei PDF-Generierung nicht funktioniert).

Ich hoffe, das hilft euch weiter!

Geschrieben von Michael *Byte* Haszprunar

Ich habe letztes Mal 4 deutsche PHP-Webseiten analysiert und kommentiert. Nun fällt mir auf, dass ich die Kurzdarstellungen und Kommentare zum PHP-Center.de, zu PHP.de und zu PHPUG.de ok finde... Aber zu Dynamic-Webpages.de finde ich rückblickend meine Aussagen zu kurz geraten bzw. zu nichts sagend. Deswegen möchte ich heute nochmals und zwar ausschließlich zu Dynamic-Webpages.de Stellung nehmen.

Tatsache bei dieser und den vorhergegangenen Kritiken ist, dass das ausschließlich meine persönliche Meinung ist. Diese Meinung hat sich auch erst beim x-ten Mal beim Betrachten der jeweiligen Webseiten heraus kristallisiert. Gerne würde ich auch Meinungen Anderer zu diesem Thema hören... Aber ich befürchte wieder mal, dass die allgemeine Meinung sich eher mit dem Punkt Desinteresse zusammen fassen lässt...

Zurück zum Thema: Den Ist-Zustand von Dynamic-Webpages kann man schnell zusammen fassen: Es wird versucht im deutschsprachigen Raum eine möglichst alles abdeckende wichtige Webseite zu bieten. Wenn ich das Impressum lese, ist hauptsächlich für den Inhalt Wolfgang Drews verantwortlich. Der Versuch eine möglichst umfassende PHP-Seite anzubieten, das ist für eine Einzelperson natürlich eine große Herausforderung, bzw. erfordert wohl einen deutlichen Zeitaufwand.

Nun, wie finde ich den Anspruch - der offiziell nirgendwo gesagt wird, den ich mal hier so nenne - eingelöst? Um das genau zu beurteilen, finde ich es notwendig bei Dynamic-Webpages auf den Inhalt von jedem einzelnen Menüpunkt eingehen.

"Deutsche PHP-Webseiten: Klatsch & Tratsch 2. Teil" vollständig lesen

Geschrieben von Gabriele Mohl

"Professionelle Softwareentwicklung mit PHP" – so lautet das Thema des dritten PHP World Kongress am 24. und 25. November 2009 in München. Präsentiert wird die Veranstaltung vom PHP Journal, dem Fachmagazin der Neuen Mediengesellschaft Ulm für Entwickler von Web-Applikationen, Contentmanager, Onlinemaganer, Agenturen und Webmaster. Auftakt der Veranstaltung bildet am 24.November die Keynote von Pierre Joye, Gründer und Leiter des Core-Teams für PHP unter Windows. Im weiteren Tagesverlauf erfahren die Teilnehmer in einem zweigleisigen Kongress, warum und wie objektorientierte Programmierung in PHP das Leben einfacher macht, was alles in Windows Azure steckt oder wie Sie die Softwareentwicklung im Team am besten planen, verwalten und strukturieren. Am 25. November bieten vier halbtägige Workshops regen Austausch mit den Referenten und sofortige Anwendung des Wissens. Auf der Agenda stehen "TYPO3"- und "PHP-5-Zertifizierung", "Suchmaschinenoptimierung" und "Entwurfsmuster mit PHP".

Alle weiteren Informationen zum Programm, den Referenten und die Anmeldung finden Sie unter www.phpworld-kongress.de.

Mitglieder der PHP Usergroup Munich sparen 100,-€ bei der Anmeldung.

Hierzu unter http://www.phpworld-kongress.de/Anmeldung.anmeldung.0.html den folgenden Code eingeben: PHP9HPUM

Geschrieben von Nils Hitze

Hi,

Ich bin bei einem Portal das ich programmiert habe über eine ziemlich fiese Sache gestolpert die ich euch nicht vorenthalten will. Im Prinzip geht es um ein Eingabefeld das ein Datum im Format "Monat/Jahr" (m/Y) erwartet.

Da ich schon ein paar Teiel vom Zend Framework verwendet habe wollte ich hier mal die geniale Funktion "isDate()" verwenden, die verspricht einen String gegen einen gegebenen Formatstring zu prüfen. In meinen Ohren klang das wie "Regex für Datum" und ich bin mir sicher ich bin nicht der Einzige dem das so geht.

Mein Formatstring war also "MM/yyyy", so wie es das ZF-Manual angibt. Es klappte zunächst auch wunderbar, denn "1/2009" wurde genau schön als true validiert wie "12/2009". Die Positives funktionierten also schonmal.

Aber das Problem ist: isDate() arbeitet nicht wie ein Regex. Es versucht nämlich - wie Excel auch - den Anwender zu bevormunden und irgendwie ein gültiges Datum zu erkennen. Das ist nicht nur nervig, es macht damit den Sinn des Ganzen zunichte. So wird ein String wie "03.2009" auch als true erkannt, obwohl in meiner Formatvorgabe ganz klar ein Slash drinsteht. Noch viel schlimmer ist dass total unsinniges Zeug auch als true validiert.

Ein Beispiel [1]:
isDate('1111','dd.MM.yyyy') ==> true WTF?
Hintergrund hier ist dass Zend_Date das so liest:
1111 -> 1.1.11 -> 01. Jan.2011 -> true

Erinnert wie gesagt stark an Excel wo genau dieses Verhalten auch jeden nervt weil es einfach nicht das tut was man dem Ding sagt sondern es tut das was es meint das man wollte. Es gibt echt nix Schlimmeres als Doftware die versucht intelligent zu sein statt einfach nur so zu funktionieren wie es sollte.

Spätestens mit dem letzten Beispiel hat isDate() für mich jeglichen Nutzen verloren. Aus dem "super, ich hab eine einfache Regex für Datumseingaben gefunden" wurde ein "verdammter Dreck, der macht ja alles falsch. Muss ich wohl doch selbst schreiben". Darüber hinaus wird isDate() auch bei Zend_Form_Validator_Date verwendet, also passt auf wenn ihr das verwendet, es kommt auch lauter komisches Zeug als true durch...

Byte gefrustet vom ZF

[1] nachzulesen ist das hier: Zend Bug #7583

Geschrieben von Michael *Byte* Haszprunar

Durch einen Eintrag von Dynamic Webpages bin ich auf den Tiobe Software Index gestoßen. In diesem Software Index wird mittels Suchmaschinenanfragen ermittelt, wie viele ausgebildete Software-Ingenieure, Kurse und "third party vendors" (=Drittmittelverkäufer?) es weltweit in der jeweiligen Sprache gibt.

Der absolute Gigant ist Java mit einem Anteil von 19%, danach C mit 17%. An dritter Stelle (seit September 2009) nun PHP mit ca. 10%, knapp vor C++.

Geschrieben von Gabriele Mohl