Neues Microblog Plugin für die Sidebar

[Dr. Love]

Nabend,

ich war irgendwie mit dem Twitter Plugin unzufrieden, deswegen habe ich ein neues Microblog-Plugin geschrieben, das eine von mir für ein anderes Projekt geschriebene TwitterApi Klasse benutzt.

Das bisherige Twitter Sidebar Plugin hatte ich zwar bereits für die aktuelle Version um die Möglichkeit erweitert, neben Twitter auch andere kompatible Services wie identi.ca zu nutzen, aber einige Dinge mochte ich daran nicht:

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.

Ich hatte sowieso meine TwitterApi zur Hand, somit habe ich das Plugin von Grund auf neu geschrieben und obige Punkte behoben. Das Plugin hat also nun folgende Funktionen, die ich für sehr angemessen halte:

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.

Vielleicht gefällt das PlugIn ja jemandem und es schafft es in den Spartacus. Gibt es Kommentare? Fehlen wichtige Features? Abgesehen von der Backup-Funktion und einer JavaScript-Variante?

Auf meinem Blog könnt Ihr das PlugIn im Einsatz sehen, bei meinem LifeStream ist die TwitterApi Klasse ebenfalls im Einsatz (dort in Kombination mit einem erweiterten SimplePie für das Feed-Handling).

[garvinhicking]

Hi!

Vielen Dank für Deine Arbeit.

Leider bin ich jetzt in einem Gewissenskonflikt. Ich hätte gerne deine Features, möchte aber auch die Features des bestehenden Plugins beibehalten. Ich z.b. benötige die Tweet-Backup-Funktion dringend.

Eine Javascript-Auswahl finde ich auch sehr gut, da man sich so nicht um Copy+Paste kümmern muss wenn man z.b. einen WYSIWYG-Editor nutzt. Zudem bietet halt auch die JS-Lösung Backupfähigkeiten, wenn man sie mag.

CuRL ist nicht überall installiert, daher sollte man definitiv einen Fallback für simplexml_load_file zur Verfügung haben.

Über die Templatefähigkeiten ist nicht zu diskutieren, das wäre toll.

Kurzum, für Spartacus möchte ich nur ein Twitter-Plugin haben. Entweder also man baut die Fähigkeiten vom jetzigen Plugin in deines ein, oder andersrum deine neuen Features in das jetzige Plugin - das Resultat davon könnte ich gerne in Spartacus einstellen!

Viele Grüße,
Garvin

[Dr. Love]

Verstehe ich gut. Vorschlag:

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.

Schon jetzt unterscheidet sich die Ausgabe der beiden Versionen nennenswert, im Sinne eines S9Y-Qualitätsversprechens halte ich schon diesen Zustand für wenig sinnvoll, zumal für jeden Nutzer sofort offensichtlich zu erkennen. Also muss IMHO an dem JavaScript was getan werden oder es muss ausgetauscht werden, mir egal. Aber in dem jetzigen Zustand würde ich das nicht gerne einbauen.

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?

cURL und simplexml_load_file: Ja, kann man als Fallback machen unter Verzicht auf sauberes Fehlerhandling einbauen. Werde ich demnächst in meine TwitterApi Klasse einbauen, sollte kein großes Problem darstellen.


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.

[garvinhicking]

Hi!

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?

Gekoppelte Plugins können sich nur über manuelle DB-Umwege eine Konfiguration teilen. Ausserdem bedeutet es einiges an Overhead, der IMHO nicht gerechtfertig ist, da das Backup eigentlich im selben Schritt ausgeführt werden kann indem das Seitenleistenplugin dargestellt wird, also garnicht an einen anderen Event gebunden. Der Code dürfte die Backup-Funktion auch eh immer nur einmalig ausführen, die wird nicht jedem neu um die Ohren geschlagen.

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.

Klar, aber die PHP-Funktion steht halt nicht überall zur Verfügung und verlagert auch die Serverpower auf den eigenen, das wollen zahlreiche Benutzer einfach auch nicht...denke also das müsste man schon in der jetzigen Form auch mitliefern.

Ich selbst setze z.B. die JavaScript-Version bei mir im Blog ein, um meinem Server keinen Parsingaufwand anzulasten. Für mich klappt das Javascript eigentlich perfekt, da sehe ich jetzt keine Qualitätsprobleme?

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?

Ja, man kann über $this->get_config() den aktuellen Wert abrufen und abhängig davon in der introspect_config_item variante einen case entweder zulassen, oder halt nicht.

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.

Kannst Du das präziser fassen? Ich habe eigentlich versucht alles reinzunehmen was es nur gibt. Rein Seitenzahlmäßig ist der Einsteiger- und der API/Plugin-Teil eigentlich 50%/50%...

Grüße,
Garvin

[Dr. Love]

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. Das ist dann halt Pech für ihn, ein weit verbreiteter Tweet-This Link für Wordpress sitzt im Template und erzeugt bei jedem Seitenaufruf einen API-Call auf tinyurl.com pro angezeigtem Eintrag(!). Da sind einmal am Tag ein bis ein paar API-Calls auf Twitter Zuckerschlecken gegen. Ich bleibe aber dabei, dass eine solche Funktion in einem Frontend-PlugIn streng genommen nichts zu suchen hat. Auch logisch nicht.

Das JavaScript werde ich etwas anders bauen, aber es wird eine JavaScript-Lösung geben.

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.

Wenn jemand auf JavaScript umschaltet, bekommt er die ganzen Cacke-Konfigs nicht mehr zu sehen, danke für den Tipp mit $this->get_config(), hätte ich auch selbst drauf kommen können.

Also meine ToDo-Liste:

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.

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.

[garvinhicking]

Hi!

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.

Ich fänds halt doof, ein existierendes Features wieder auszubauen. Jeder Benutzer des Plugins (mir inklusive) wäre es nicht recht, ein neues Plugin zu installieren um quasi den Komfort zu behalten, den man schon hat. Serendipity legt eigentlich viel Wert auf Rückwärtskompatibilität, und ich sehe eigentlich keinen Grund, das Feature auszubauen. Die Methode ist recht gekappselt, dürfte die Maintainability daher kaum betreffen.

Kurzum: Ich würde dafür nicht extra ein weiteres Plugin installieren, sondern dann würde ich hingehen und mir einen eigenen Cronjob dafür bauen. Es ist mehr Wartungsaufwand dann ein zweites Plugin zu konfigurieren und zu betreiben, als es einspaart jetzt auszulagern.

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

Das ist aber vernachlässigbar, denn die Daten werden ja in 'nem PHP-Parsingfall z.b. eh gezogen. Die paar ms die es dauert, 5 neue Tweets abzuspeichern sind ja marginal. Also ich denke, dass ist kein reales Problem.

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.

Das stimmt, die nicht anklickbaren Links finde ich aber nicht so tragisch. Letztlich müsste man es nur wie in PHP umsetzen dass es auch einen Parser hierfür gibt. Sprich, das ist ja eher nur ein fehlendes Feature, und nicht mangelnde Qualität des bestehenden. Mir persönlich ist es nicht so wichtig dass es exakt gleich aussieht, sondern lediglich dass ich auf den PHP-API-Kram verzichten kann.

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

Ich möchte lediglich einen einfachen Updatepfad. Ich will das serendipity_plugin_twitter aktualisieren und dann die gleichen Funktionen haben die ich vorher schon hatte, und mich nicht darum kümmern müssen (vielleicht weil ich es garnicht mitkriege!) dass plötzlich ein Feature rausgekickt wurde.

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.

Naja, ich finde dass die Pluginbeschreibung schon deutlich über das hinaus geht, was im Plugin selbst steht. Klar versucht s9y aufgrund der mangelnden online-dokumentation von plugins so selbsterklärend wie möglich zu sein, ich denke aber das Buch beschreibt die Sachen dann schon deutlich so, ohne dass man selber experimentieren muss.

Die Plugin API habe ich eigentlich schon versucht im Kern darzustellen. Vieles lernt man erst durch Beispiele und nutzung der dokumentierten Funktionen. Dafür habe ich ja versucht auch auf die Dateien hinzuweisen - Learning by Doing bringt hier den meisten erfolg.

Naja, grundsätzlich ist es bei dem Buch natürlich schon ein Problem weil ich zwischen Einsteigern und Profis vermitteln will, und alles in einem Buch zusammentragen. Serendpity ist zu klein, um mehrere Bücher am Markt zu rechtfertigen - und wirklich gute PHP-API-Anwendung ist auch ein thema, das weit über s9y selbst hinaus geht. Da ist es schwer ein Ende und einen Anfang zu finden.

Ich will also Deine Kritik nicht abweisen, sondern sehe schon ein, dass man immer noch mehr gezielt beschreiben könnte. Aber irgendwo musste ich auch ein Ende finden, und ein Gesamtkonzept vermitteln. Für konkrete Fragen und Probleme habe ich immer auch versucht aufs s9y Forum (und existierenden Code) hinzuweisen, und freue mich natürlich auch wenn gerade wie in deinem Fall dann genau eine solche Diskussionsmöglichkeit auch genutzt wird.

Viele GRüße,
Garvin

[Dr. Love]

Ich setz mich mal ran, bin gerade heiß und hab keinen dringenden Auftrag.

[Dr. Love]

Also der simplexml_load_file Fallback für cURL ist jetzt drin und auch die Backup-Funktion arbeitet.

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.

Zumindest auf meinem lokalen Entwicklungsserver verzögert ein (deswegen nötiges) Vollbackup den Seitenaufbau übrigens um bequem 15 Sekunden bei knapp 400 identi.ca Dents (jaja, identica ist nicht so fix). Gut, dass das nur einmal gemacht werden muss. Allerdings gibt es hier ein böses Problem, das ich nicht zu lösen weiß: Bricht der Prozess wegen zu langer Skriptkaufzeit (oft nur 10 Sekunden) ab, werden die älteren Tweets nie mehr importiert. Das nächste Backup sieht nur: "aha, der neueste tweet ist soundso" und macht da weiter. Twitter liefert leider seine Tweets in absteigender Reihenfolge aus und da wir Seitenweise einlesen, können wir auch nicht einfach alles umdrehen und hinten anfangen.

Die JavaScript Lösung folgt, deswegen noch kein neuer Code.

[Dr. Love]

So, hab fast alles fertig. Das JavaScript ist auch komplett neu und kann jetzt eigentlich alles, was die PHP-Version auch kann, die beiden teilen sich sogar die die Smarty-Templates, von denen ich zwei mitliefere, die Konfiguration und die Sprachstrings. Das Plugin reicht alles nötige in einem JSON-Objekt an das Script durch und das macht etwa das gleiche, wie die PHP-Version.

Auf dem Weg ist mir allerdings aufgefallen, dass ich einige Sprachkonstanten als Array brauche, weil ich sie an das JavaScript durchreichen muss. Reißt Du mir den Kopf ab, wenn ich für dieses PlugIn alle Sprachkonstanten rauswerfe und durch ein Pluginspezifisches $lang-Array ersetze? Ich halte mich ja gerne an Konventionen, aber momentan habe ich Konstanten und ein Array da drin und das ist irre kompliziert zu handhaben (wegen der englischen Fallback-Lösung, die das deutsche array überschreibt, aber nicht die Konstanten und umgekehrt).

Was mir jetzt nur noch fehlt ist Testing, ein Code-Audit und eine Funktion für das JavaScript, die PHP date() kompatible Strings verarbeiten kann. Gibt es sowas schon fertig?

[garvinhicking]

Hi!

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.

Das würde ich anders lösen, und bei einer Tabelle bleiben. Dort einfach eine neue Spalte "instanz-id" einfügen. Dann kann das Plugin beim instanzieren eine Versiosnvariable prüfen, wenn die leer ist, wird die bestehende Tabelle mit der Spalte per ALTER TABLE nachgreicht. Schau mal wie das staticpage-Plugin das z.b. macht um seine Tabellen zu aktualisieren.

Der Rest klingt ja sehr vielversprechend, und nach einer Menge Arbeit.

Das mit den Sprachkonstanten halte ich nicht für elegant, da müssen übersetzer sich ja völlig umorientieren. Leite doch die Sprachkonstanten einfach manuell an ein array weiter:

Code: Select all

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

Das mit dem Problem der Fallbacklösung verstehe ich nicht ganz?

Testung und Audit kann ich gerne soweit versuchen, wenn Du das alles soweit fertig hast...zu der date() Funktion hab ich leider keine Ahnung.

GRüße,
Garvin

[Dr. Love]

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. So sehr müssen sich Übersetzer also nicht anpassen, oder hast Du irgendwelche Tools dafür, die auf die Lösung mit den Konstanten angewiesen sind. Bedenke auch, dass man das mit den vielen @define sowieso vermeiden sollte, weil es verhältnismäßig langsam ist, weil es die komplette Fehlerbehandlung kurz aus- und dann wieder einschaltet. Und das muss bei jedem Aufruf (wegen des en-Fallbacks) gleich zweimal gemacht werden, egal ob der Output-Cache den Rest umgeht oder nicht. Ich würde für dieses PlugIn also wirklich sehr gerne mit einem Language-Array lösen, ob global oder nur im Scope des PlugIns sichtbar, muss man sich noch überlegen, ich werfe nicht gerne meinen Dreck in den globalen Scope rein, der da nicht gebraucht wird. 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. Dass vielleicht ein paar Übersetzer beim ersten Blick überrascht sind, halte ich für verschmerzbar, zumal mein $lang-array bei der Gelegenheit gleich mehrdimensional angelegt ist (etwa die Wochentage und die Strings für verschiedene Funktionen in eigenen Arrays), was die Verarbeitung immens erleichtert. Das alles müsste man erst mühsam und aus den Konstanten wieder aufbauen. Bitte lass mich das mit einem Array lösen.

Das mit der Fallbacklösung für die Sprachdatei ist nur ein Problem, wenn man Konstanten und Array in einer Datei mischt. Hab ich aktuell so, weil ich vor einer vollen Umstellung auf ein Spracharray lieber noch mal nachfragen wollte.


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.

P.S. Das JavaScript war wirklich viel Arbeit, weil ich die Sprache nicht wirklich kenne. Musste also alles aus irgendwelchen Dokus zusammensuchen. Meine PHP-Funktionen ließen sich aber überraschend direkt portieren.

[garvinhicking]

Hi!

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.

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.

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.

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.

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.

"introspect" ist quasi der Konstruktur, ja.

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

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

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.

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.

Grüße,
Garvin

[Dr. Love]

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.

Man muss das ja nicht selber machen

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.

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.

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.

Bei der Scope frage geht es mir nicht um die Konstanten. Wenn ich das mit einer $lang-Variable gemacht hätte, wäre das relevant gewesen, ob es eine große $lang fürs ganze System gibt (ich hab keine gesehen) oder eine $lang je PlugIn. Also alles klar, Konstanten, die in ein Array geschrieben werden.

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

Ja, fein, das hatte ich gesucht.

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.

Wenn es keinen Cache gibt, wird der sowieso neu geschrieben und alles ist gut. Es geht nur um Änderungen der Konfig, und da ist ja die cleanup() der richtige Ansprechpartner.


Für die date() Funktion in JavaScript hb ich auch eine Lösung gefunden: PHPJS heißt das Projekt und portiert PHP-Funktionen nach JavaScript. Fein.

[Dr. Love]

So, hab alles soweit fertig. Bitte um Testing und vielleicht ein Blick in den Code, falls ich was übersehen habe. Bei mir funktioniert es jedenfalls prima.

[garvinhicking]

Hi!

Bevor ich's vergesse, hier war noch ein Bug/Feature-Wunsch: http://board.s9y.org/viewtopic.php?f=2&t=14913&start=0

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.

Nein, install() wird wie der Name suggeriert nur beim installieren aufgerufen

Updates haben Plugins bisher immer selbst verwaltet anhand einer Versionsnummer einmal im Plugin und einmal in der Datenbank. Wenn die nicht übereinstimmt weiß das Plugin, da gibt's was zu tun.

Das Plugin werde ich versuchen mir heute mal testend zu Gemüte zu führen.

Grüße,
Garvin