Archiv für den Monat: März 2010

Mathematische Strings mit PHP auswerten

Wer immer einen mathematischen Ausdruck in einem String auswerten bzw. ausrechnen möchte, muss ein wenig in die Trickkiste von PHP greifen.

Aber mal langsam, wir beginnen mit der Aufgabe:

$mystring = „123*1.1“;

Der String selbst kommt von irgendwo z.B. aus einem Formular und soll einen Wert + 10% berechnen. Wie machen wir das in PHP? Ein einfaches

echo $mystring;

reicht da nicht aus.

Nach ein bischen suchen im Handbuch kam ich auf diese Lösung, nicht schön, aber es geht:

eval(‚$ergebnis = ‚.$mystring.‘;‘);
echo $ergebnis;

Auf das Ergebnis kann man nun bequem zurückgreifen.

Okay, hier fehlen noch ein paar Sicherheitsmechanismen (eval is evil), aber der Grundsatz sollte klar sein und solche Funktionen sind schnell nachgerüstet (siehe die Filter-Sektion im Handbuch).

Generell sollte man eval natürlich vermeiden, aber in speziellen Anwendungen – wie in diesem – kann es durchaus Sinn machen, die “böse” Funktion zu nutzen.

Ich bin schon mal froh, diese Funktion zu haben und will diese euch nicht vor enthalten.

Läuft, läuft nicht, läuft nicht immer …

Eine neue tolle Web-GUI, umgesetzt mit jQuery. AJAX, Bilder, Layout und Farben, alles perfekt abgestimmt, mehrmals auf Funktion getestet, auch auch verschiedenen Rechnern.

Alles super.

Also: Freigabe, Bekanntgabe der URL und auf Lob warten.

Kurze Zeit später, der Endbenutzer am Telefon, in Erwartung von (verdientem) Lob gehe ich ran, nur um zu hören: “Geht nicht!”.

Völlig perplex öffne ich die Seite, alles funktioniert.

HTML lädt, CSS: perfekt, Javascript: vorhanden, jQuery: alles roger.

Woran liegt’s dann?

Fehlerkonsole vom Firefox aufgemacht und siehe da: Eine Fehlermeldung: “console nicht bekannt“ in Zeile xyz”

Cool, ein vergessenes Kommando “console.log”, die uns zu debugzwecken Ausgaben in Firebug liefert, führt nun dazu, dass der Endbenutzer unsere schöne GUI nicht bedienen kann, weil der natürlich nicht Firebug installiert hat. Großes Aha!

Kleine Ursache, lange Suche …

jQuery und der HTML-Head Bereich

Habe grade etwas länger zur Lösung dieses Problems verpulvert und möchte damit allen helfen, die ähnliche Probleme haben.

Ziel war es, über eine Suchfunktion mittels AJAX und jQuery ein neues Tab zu öffnen und dort die Suchinfos darzustellen und zwar ebenso, wie schon bereits vorher angezeigte “festen” Infos dargestellt wurden. Dazu gehörte auch, dass ein Klick auf eine Zeile einen jQuery-Dialog öffnet und dort mehr Informationen angezeigt werden.

Nun, die “normalen” Informationen mit dem jQuery-Dialog anzuzeigen war kein Problem, das Problem entstand, als ein neues jQuery-Tab hinzukam, dass die Ergebnisse der Suche als GET-Request darstellte (jQuery-Tab mit URL als Referenz).

Nach der Durchführung einer Suche funktionierte keine jQuery-Funktion mehr, also öffnete sich kein Info-Fenster.

Nun, ich mache es kurz: Die Lösung ist nun, dass in der Antwort des Requests nicht nur die Daten mit Layout enthalten waren, sondern eine komplette HTML-Seite und diese auch inklusive Bereich. Und dort war wiederrum ein Verweis auf jQuery enthalten; allerdings ohne die Datei, die die ganze jQuery-Logik für diese Seite beinhaltet.

jQuery lädt also neu und “kennt” dannach die Logik für die aktuelle Seite nicht mehr; ergo: Keinerlei Funktion mehr auf der Seite.

Evtl. sollte jQuery hier nachbessern und die im Speicher befindlichen Scripte nicht “vergessen”, wenn es sich selbst neu lädt. Am besten, es läßt sich gar nicht mittels eines neuen Aufrufes von neu laden, denn das störte an dieser Stelle das Vorwärtskommen doch enorm.

So, ich hoffe, ich konnte irgendeinem von euch helfen, so daß ihr nicht allzulange braucht, um eure Problem zu lösen.

Homepage für andere sperren

Während man eine Webseite erstellt oder bearbeitet, möchte man natürlich nicht, dass andere einen “Zwischenstand” sehen und man sperrt die Domain. Oder man möchte einfach allein auf seiner Homepage rumsurfen … warum auch immer.

Zuerst braucht Mensch seine IP, dazu gibt es genug AddOns oder Webseiten, auf denen Mensch das rausbekommt.

Dannach braucht es noch zwei Zeilen in der .htaccess; RewriteEngine sollte “on” sein.

RewriteCond %{REMOTE_ADDR} !^IPADRESSE$
RewriteRule ^(.*)$ URL_ZUR_UMLEITUNG [NC,QSA,L,R=302]

Wichtig ist das ! vor der PrüfungsIP-Adresse in der RewriteCond Zeile.

Somit sehen alle anderen Besucher die URL die bei der RULE eingegeben wird, Mensch selbst sieht aber die “normalen” Inhalte.

Kleines Beispiel (Domain ist my-example-web.com)

RewriteCond %{REMOTE_ADDR} !^78.201.9.12$
RewriteRule ^(.*)$ http://example.com [NC,QSA,L,R=302]

Hier greifen alle User auf example.com zu, nur der User von der IP 78.201.9.12 (sollte die eigene sein) greift auf die “echten” Inhalte der Seite zu.

Referenz: Doku zu RewriteCond

Benutzereingaben prüfen: Leere Strings

Ich kenne viele Wege, einen String daraufhin zu prüfen, ob der User

a) überhaupt was eingegeben hat und
b) ob der User außer Leerzeichen was eingegeben hat.

In jeder Sprache gibt es dafür viele Wege, einige gut, viele nicht so gut.

Heute mal ein Beispiel aus der Reihe “not so good”:

if

(strlen($tls_description) > 1 && substr_count($tls_description,“ „) >= (strlen($tls_description) – substr_count($tls_description,“ „)))
{
   $err = true;
}

Mein Ansatz, genauso gut, dafür lesbar und ebenso “effektiv”:

if

(strlen(trim($tls_description))<1)
{
   $err = true;
}

Nicht nur schneller, sondern auch lesbarer und nicht so WTF?