Serendipity Forums

1. Eine Backup-Funktion für Tweets ist zwar nett, aber hat in meinen Augen rein gar nichts in einem Sidebar-Plugin verloren. Sowas kann man woanders als eigenes Plugin (oder Doppelplugin) bauen.
2. Die Auswahl zwischen einer JavaScript-Lösung und einer PHP-Lösung sorgt für hohen Anpassungsaufwand und bringt einen nicht so recht nach vorne: Wer eine javaScript-Lösung haben will, kann ein beliebiges Widget in ein HTML-Nugget packen und braucht dafür kein extra Plugin. Der Markt hat eine Menge Lösungen dafür parat.
3. Auf manchen Servern ist (nicht ganz unklug) allow_url_fopen ausgeschaltet, also sollte der API-Call anders geladen werden (also anders als simplexml_load_file(externe url)). Ich ziehe hier cURL vor, auch, weil man damit Fehler besser abfangen kann.
4. Ich wollte das ganze gerne templatefähig.

1. Doppeltes Cache-Konzept: Die TwitterApi Klasse cacht sich selbst, um API-Calls zu vermeiden. Diese Zeit ist in der PlugIn Konfiguration einstellbar. Dann wird das Ganze PlugIn nochmal mit einem zweiten (abschaltbaren) Cache umgangen, der 30 Sekunden lang einfach nur vorgerenderten HTML-Code ausgibt. Damit spart man sich ne Menge Rechenarbeit, falls der Server viel Traffic hat.
2. Smarty Templating: Die Ausgabe des PlugIns lässt sich vollständig templaten, ein Template auf ul/li Basis liegt bei.
3. Klickbare URLs, #hashtags, @namen und !gruppen: Ein abschaltbares Kernfeature meiner TwitterApi Klasse.
4. Hübsche Zeitstempel und klickbare Metaangaben: "vor 23 Minuten via Thwirl als Antwort auf benutzerxy", so wie man das vom Twitter-Client der Wahl kennt.
5. Stabile Codebasis mit Exception Handling: Aussagekräftige Fehlermeldungen und inline Dokumentation erleichtern die Handhabung für den Entwickler.
6. Nutzung von cURL statt url_fopen: Sichere Server haben häufig allow_url_fopen deaktiviert, außerdem sorgt cURL für saubereres Fehlerhandlung.
7. Leichter Erweiterbarkeit für neue Dienste: Neue Twitter-API kompatible Dienste sind sehr leicht hinzuzufügen.

Twitter-Backup wird ein gekoppeltes Event-PlugIn. Wobei ich mich in gekoppelte PlugIns noch nicht eingearbeitet habe. Können die sich eine gemeinsame Konfig teilen und dann gibt es ein PlugIn für die Sidebar und ein weiteres Event-PlugIn? Das würde sich geradezu anbieten, um dort dann die Backup-Funktion einmal am Tag laufen zu lassen. Vielleicht sogar erst auf Knopfdruck oder beim Login im Backend, damit nicht ein armes Schwein am Tag die Ladezeit dafür um die Ohren gehauen bekommt. Wenn ich das richtig sehe, muss man dazu einfach andere Hooks abhören, richtig?

Die JavaScript Version fällt leider funktional massiv ab gegenüber der PHP-Version (klickbare Links, Templating, aktuell auch Metainformationen (via und als Antwort auf). Lässt sich alles machen, ist aber eine völlig andere Baustelle, die bis auf die Konfiguration für Dienst, Username und Itemanzahl rein gar nichts gemeinsam hat mit der PHP-Version. Andererseits spricht auch außer meinem Eleganzempfinden nicht viel dagegen, die einfach mitzuliefern und sich nicht weiter drum zu kümmern. Oder jemand anderes macht das und wir stellen nur die Konfig bereit. Bin kein JavaScript Experte.

Kann man auf der Konfigseite des PlugIns je nach Auswahl eines einen Wertes andere verstecken? Im Falle von JavaScript würde man dann die ganzen Cache-Sachen ausblenden. Ist sowas vorgesehen?

P.S. Das Kapitel über eigene PlugIns kommt in Deinem Buch für meinen Geschmack etwas kurz gegenüber den etlichen hundert Seiten Beschreibung dessen, was jeder interessierte User spätestens nach ein paar Wochen sowieso gesehen hat.

1. simplexml_load_file() als Fallback für cURL lose Zeitgenossen einbauen
2. Twitter-Backup Lösung adaptieren, hier sehe ich noch Diskussionsbedarf, vielleicht kann ich Dich ja noch überzeugen, das als eigenes PlugIn zu machen
3. Eine JavaScript-Variante integrieren, dabei ggf. die bestehende aus dem Twitter-PlugIn als Basis hernehmen oder eine bessere auftreiben oder selber schreiben. Features: Template der PHP-Version irgendwie nutzen, klickbare #tags etc. und hübsche Zeitstempel. Anregungen willkommen.

Dr. Love wrote:Mir würde für die Twitter-Backup-Funktion ein zweites PlugIn besser gefallen. Letztlich haben die beiden ja nur eine Konfiguration für Dienst und Nutzername gemeinsam. Aber ich kann die Backup-Funktion auch adaptieren. Mir schwebt schon eine elegante Lösung vor. Mal schauen.

Trotzdem bleibt hier das Problem, dass bei einem Besucher pro Tag die Ladezeit durch das Backup verlängert wird.

Die Qualitätsprobleme sehe ich darin, dass die JavaScript-Lösung momentan nichts anklickbar macht und anderen Code erzeugt, der nicht von einem Template gedeckt ist. Das werde ich aber irgendwie angehen. Ganz gleich werden die beiden vom Output her aber nicht sein. Mich hat das ehr irritiert, als ich das Twitter-PlugIn damals installiert habe.

[*]Twitter-Backup Lösung adaptieren, hier sehe ich noch Diskussionsbedarf, vielleicht kann ich Dich ja noch überzeugen, das als eigenes PlugIn zu machen

Zum Buch: Ich meine Kapitel 10.8 über die PlugIn API hat nur gut 30 Seiten und demgegenüber werden hunderte Seiten lang einfach nur PlugIns beschrieben. Letzteres aber auch nicht wirklich tiefgehender als das, was man sowieso sieht, wenn man das PlugIn installiert und die Konfig-Seite aufruft. Immerhin steht so alles drin. Also vergiss meinen Einwand.

Allerdings musste ich die Abwärtskompatibilität brechen: Das alte Backup hat immer in die Tabelle 'PREFIX_tweets' gespeichert. Da das PlugIn aber stackable ist, würden sich mehrere Instanzen furchtbar in die Quere kommen, ganz besonders bei verschiedenen Diensten. Aus diesem Grund legt das PlugIn nun Tabellen nach dem Schema 'PREFIX_microblog_DIENSTNAME_USERNAME' an. Wer jetzt zweimal das gleiche PlugIn installiert, macht nur Server- und API-Last, aber kann (auch mit gleichen Einstellungen) nichts durchinander bringen.

$lang_constants = array(PLUGIN_BLA1, PLUGIN_BLA1, PLUGIN_BLA1, PLUGIN_BLA1,...);

Dr. Love wrote:Das Problem mit der Backup-Tabelle ist folgendes: Die Status ID des Tweets/Dents/Wasauchimmer wird momentan als Primärschlüssel hergenommen. Hat man zweimal Twitter ist das OK, dann kommen die sich nicht in die Quere. Hat man verschiedene Dienste, können die IDs aber durchaus kollidieren. Deswegen lege ich eine Tabelle je Dienst an. Das ließe sich zwar auch anders lösen, aber dann müsste man die Tabelle ja noch mehr umbauen und bestehende Daten umkopieren, also tweetid müsste ein normales Feld werden und es müsste einen neuen Primärschlüssel geben (oder gar keinen, in der Tabelle wird ja nicht wirklich gesucht). Das würde natürlich gehen, aber ist das eleganter als eine eigene Tabelle je Dienst?

Zu den Sprachkonstanten: Aua, das wäre ja die total doppelte Arbeit. Konstanten definieren, mit anderen @defines versuchen zu ergänzen und dann an anderer Stelle doch in ein Array packen. Ob man nun

@define('KONSTANTE_STRING1', 'Übersetzt1');
@define('KONSTANTE_STRING2', 'Übersetzt2');

schreibt, oder

$lang['plugin_micoblog'] = array(
'string1' => 'Übersetzt1',
'string2' => 'Übersetzt2',
);

ist nicht grundlegend verschieden im Workflow.

Sprich: Ich würde die Lang-Variable im Konstruktor des PlugIns (gibts da überhaupt einen? Bzw. würde der aufgerufen werden?) initialisieren und alle Methoden können das dann nutzen.

Apropos Cache: Gibt es eine Möglichkeit, etwas nach dem Speichern der Einstellungen eines PlugIns zu machen?

Dann würde ich für die JavaScript Variante nur einmal beim Verändern der Konfiguration einen Output Cache schreiben und sonst alles umgehen. Du weißt ja, unnötiges Verzögern zu verhindern ist das a und o bei Sidebar-PlugIns. Notfalls kann man das ja auch bei jedem Aufruf der Konfig-Seite machen. Der PHP version würde es auch nicht schaden, wenn eine Konfig-Änderung den Output cache löscht. Sonst muss man 30 Sekunden auf die Änderung warten.

garvinhicking wrote:

Dr. Love wrote:Das Problem mit der Backup-Tabelle ist folgendes: Die Status ID des Tweets/Dents/Wasauchimmer wird momentan als Primärschlüssel hergenommen. Hat man zweimal Twitter ist das OK, dann kommen die sich nicht in die Quere. Hat man verschiedene Dienste, können die IDs aber durchaus kollidieren. Deswegen lege ich eine Tabelle je Dienst an. Das ließe sich zwar auch anders lösen, aber dann müsste man die Tabelle ja noch mehr umbauen und bestehende Daten umkopieren, also tweetid müsste ein normales Feld werden und es müsste einen neuen Primärschlüssel geben (oder gar keinen, in der Tabelle wird ja nicht wirklich gesucht). Das würde natürlich gehen, aber ist das eleganter als eine eigene Tabelle je Dienst?

Ich würde dann den Primärschlüssel aufheben und als kombinierten schlüssel aus ID+Dienste-ID einführen. Es ist schon deutlich sinnvoller, nur eine Tabelle zu halten, damit man nicht für jeden später hinzugefügten Dienst eine neue Datenbanktabelle erstellen muss.

garvinhicking wrote:Umkopieren musst du nicht, du kannst für die alten Tabellen ja einfach den Dienste-ID-Schlüssel auf "twitter" vorbelegen, dann geht das alles mit ALTER TABLE durch.

Diese Lösung wäre dann halt abwärtskompatibel und wartungsfreundlicher.

garvinhicking wrote:Es wiederspricht aber dem üblichen s9y konzept. Es gibt Tools die auf die sprach-Konstanten zugreifen (von Vlada Ajgl ein .jar tool) das würde mit deiner Syntax nicht mehr funktionieren. Die Sprachkonstanten sind Vorgabe, daran sollte man sich aus Gründen der Einheitlichkeit einlassen.

In meinen Benchmarks waren Dateien mit 10.000 @defines ungefähr 0,1% langsamer als nur "defines". Und s9y ist halt einfach auf Konstanten ausgelegt, das zu ändern wäre ein sehr großer Aufwand für den es derzeit noch zu wenig "Nutzen" gibt.

Bitte nenn doch mal konkret deine Konstanten die Du brauchst und warum die nicht im Plugin-Scope verfügbar sein sollten. Noch kann ich nicht verstehen, worauf Du Dich in dem Problem beziehst.

garvinhicking wrote:Ja, über die Methode "cleanup" eines Plugins, die wird von jedem Plugin nach dem Speichern aufgerufen.

garvinhicking wrote:Grundsätzlich ist das eine gute Idee, man müsste nur sicherstellen dass das plugin auch nach der erstinstallation klappt wo ein user vielleicht noch nie auf "speichern" geklickt hat und daher cleanup() noch nie aufgerufen wurde. D.h. Du musst gegebenenfalls auch über die install() methode das ganze aufrufen.

Hmm, na gut. Stimmt. Ein ALTER TABLE tuts auch. Ich würde das dann aber bei der install-Methode machen, die wird sicher auch bei einem Update aufgerufen, oder? Jedes mal beim Backup das zu machen ist ja überflüssig.