Archiv für den Monat: August 2010

10 Gründe, PHP zu mögen…

…stellt Stephan Elter von phphatesme.com vor.

Alle Gründe lassen sich problemlos unterschreiben und somit geht ein Linktip von mir heute an den Beitrag „10 Gründe warum ich PHP mag“ von phphatesme.com, den ich absolut Lesenswert finde!

Eine Liste aller Seiten mit webEdition

Eine Liste über alle oder nur bestimmte Seiten auf seinem Webspace ist immer nützlich, z.B. als Sitemap, als Übersicht der neuesten 10 Seiten, für’s RSS Feed oder oder oder.
Der Ablauf, wie man das ganze mit webEdition realisiert, ist im Prinzip immer der gleiche. Das Zauberwort bzw. we-Tag, welches man dazu braucht, nennt sich we:listview.

Mit einer we:listview erhält – mit einer der vielen „type“-Attribute – auch alle Dokumente, die einem bestimmten Filter entsprechen. Einzig zwingendes Attribut bei we:listview ist das „type“-Attribut, welches für den aktuellen Fall auf „document“ gesetzt wird.

Eins vorweg: we:listview erfasst Dokumente nur unter zwei Bedingungen:
Entweder die Dokumente haben in den „Eigenschaften“ das Attribut „durchsuchbar“ gesetzt oder man setzt das Attribut searchable des we:listview auf „false“.

Durchsuchbar vs. searchable
searchable ist der einfachste Fall, dabei werden allerdings alle Dokumente erfasst, die das entsprechende Feld „durchsuchbar“ auf „False“ haben. Das die Dokumente dieses Attribut nicht gesetzt haben, dürfte der normalfall sein. Dageben findet „searchable=true“ nur Dokumente, die das entsprechende Feld auch gesetzt haben.
Nun das für und wieder:
Im Fall „searchable=false“ erfasse ich alle Dokumente und kann mit setzen der Eigenschaft „durchsuchbar“ ein Dokument von der Suche ausnehmen. Sinnvoll, wenn nur wenige Dokumente _nicht_ in der Suche erscheinen sollen.
Im anderen Fall kann ich exakt steuern, welche Dokumente gefunden werden dürfen.
Welches von beiden man wählt kommt auf den Anwendungsfall an.

Filter nach Typ
Will man nur bestimmte Dokumenttypen erfassen – die we:listview benennt Dokumente nicht nur nach webEdition Dokumenten, sondern auch Bilder usw.; ein we:listview Dokument ist etwas, was physikalisch auf dem Server liegt – dann muss man „contenttypes“ setzen. Im Falle von „neueste 10 Seiten“ oder „Sitemap“ setzt man dies auf „text/webedition“. Dann erfasst man alle Seiten, die man auch mit webEdition erstellt hat und bearbeiten kann.

Filtern nach Verzeichnissen
Manchmal möchte man nicht „alles zeigen“, sondern nur Seiten aus bestimmten Verzeichnissen. Dann gibt man die ID der Verzeichnisse einfach im Attribut „workspaceID“ als komma-separierte Liste an. Möchte man zusätzlich noch Unterverzeichnisse einbeziehen, dann muss das Attribut „recursive“ auf „true“ gesetzt werden.

Startpunkt und Anzahl der Links
Schön zum begrenzen der angezeigten Links: „rows“ und „offset“.
Mit „rows“ legt man fest, wieviele Treffer gezeigt werden, mit „offset“ bestimmt man … nunja, den offset halt. Diese Einstellungen werden für z.B. für eine Blätterfunktion genutzt, der interessierte Leser liest dazu bitte das Beispiel auf der Referenzseite an und sieht bei den Tags „we:listviewPageNr“, „we:listviewPages“, „we:next“, „we:ifNext“, „we:back“ und „we:ifBack“ nach.

Sortierreihenfolge und -richtung
Braucht man eine Sortierreihenfolge, dann setzt man „order“ auf einen dieser Werte:
random() -> Zufällige ausgabe
we_creationdate -> Erzeugungsdatum
we_filename -> Dateiname
we_id -> Die ID
we_published -> Wann veröffentlicht
we_moddate -> Zuletzt geändert

Normalerweise werden die Einträge aufsteigend sortiert, benötigt man absteigende Sortierung, setzt man „desc“ auf „true“ (z.B. für die neuesten Seiten wichtig).

Weiteres
we:lisview bietet noch viele weitere Optionen, die ich selbst bisher nicht gebraucht habe und für dieses Beispiel einfach zu viel sind. Ich bitte den geneigten Leser, mal in der Doku zu we:listview nach zu schlagen … auch wenn diese bisweilen nicht so ergiebig ist, wie man es sich oft wünschen würde.

we:repeat und we:field
Um durch die Treffer zu iterieren, benötigen wir das we-Tag we:repeat, dass dann von „offset“ bis „rows“ die Treffer der Reihe nach ausgibt. Die Informationen zu den Treffern findet man in we:field, über dessen Attribute kommt man dann an alles, was benötigt wird.

Ein Beispiel
Auf einer meiner Seiten gebe ich die 5 Dokumente aus, die ich mit webEdition veröffentlicht habe, allerdings dürfen diese nur in bestimmten Verzeichnissen liegen und müssen dazu noch das Attribut „durchsuchbar“ gesetzt haben. So kann ich ganz genau steuern, welches Dokument dort auftaucht und welches nicht. Dieser Ausschnitt hier ist 1:1 und liegt in einem Template namens „listviewtest.tpl“









Ich kann nun die Darstellung der 5 neuesten Dokumente einfach mittels



oder



in meine Vorlagen einbinden.

Für eine Sitemap sollte man das Attribut „rows“ evtl. weglassen, so dass alle Dokumente angezeigt werden, ebenso kann man sich natürlich was für Darstellung überlegen.

Das hier soll nur ein Einstieg sein und ich hoffe, ich konnte euch das „rüberbringen“. Die Erstellung von Listen auf Basis der webEdition Dokumente sollte nun kein großes Problem mehr sein.

PHP-Snippet: int2bin

Integer zu Binär casten:


function int2bin($number)
{
$number = filter_var($number,FILTER_SANITIZE_NUMBER_INT);
return ($number=='') ? FALSE : base_convert($number, 10, 2);
}

Eingabe: Eine Zahl oder ein String mit Zahlen darin.
Rückgabe: FALSE, wenn keine Zahl in $number gefunden wurde oder die entsprechende Binär-Ausgabe der Zahlen in §number.
Hinweis: $number=’A21′ erhält ‚10101‘ als Rückgabe!

Achtung: boolean filtern mit filter_var()

Wer seine Eingaben prüfen will, kommt um Filter nicht mehr rum. Ganz rudimentär und ohne „externe“ Frameworks kommt man aus, wenn man filter_var() benutzt.
Doch Achtung: Eine Validierung auf boolean in diesem Stil geht schief, denn:

filter_var('1', FILTER_VALIDATE_BOOLEAN);
filter_var('0', FILTER_VALIDATE_BOOLEAN);
filter_var('abc', FILTER_VALIDATE_BOOLEAN);

Folgende Ergebnisse:

1 -> true
2 -> false
3 -> false

Die ersten beiden Fälle sind richtig – obwohl man bei Zeile 2 auch ein true erwarten dürfte, denn die 0 ist ein boolean-Wert und damit könnte die Prüfung auch true sein, wenn man mit der Absicht prüft, ob es denn überhaupt ein boolean-Wert ist oder nicht, nicht welcher boolean-Wert vorliegt. Das klärt sich aber gleich – , der dritte Fall ist nicht gewollt oder nach der o.a. Logik ist diese Zeile richtig und Zeile 2 falsch, je nach Ansicht.

Klar ist aber jedem, dass man damit nicht arbeiten kann. Für ein Ergebnis, mit dem man arbeiten kann, muss man eine Option in filter_var() mit dem dritten Parameter setzen.

filter_var('1', FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE);
filter_var('0', FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE);
filter_var('abc', FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE);

Ergebnisse nun:

1 -> true
2 -> false
3 -> null

Und damit kann man nun sehr gut arbeiten…

Memo an mich selbst #1

Lieber Sascha,

  1. Versuche nicht, eine Zend_Mail ohne addTo zu senden #pfui #böse
  2. setFrom ist bei Zend_Mail wirklich sinnvoll zu setzen #thumbsup
  3. jQuery.post result data auf größer-gleich 1 prüfen, nicht auf größer 0 #uiuiui
  4. Zend_Mail->send schmiert ab, wenn die Adressen ein ( oder ) enthalten #pfuipfui
  5. Lobet den Debugger im Zend Studio #thumbsupupup
  6. Preiset Firebug #findeKeinGeeignetesTag
  7. Lade die geänderte config-Datei auch hoch, du Depp! #facepalm

Ansonsten alles Spaghetti…
Schönen Abend noch…