Idee für neues Addon: be_extensions

[RexDude]

EDIT: Addon wurde mittlerweile hier unter neuem Namen offiziell released: http://www.redaxo.org/de/forum/addons-f ... 19142.html

----------------------------------------------------------------------------------------------------

Hallo zusammen,

ich möchte hier gerne meine Idee für ein neues Addon vorstellen.

Hintergrund:
Bei mir sammeln sich immer mehr Mini Addons/Plugins in einer REDAXO-Installation, die haupstächlich Funktionalität zum Backend beisteuern.

Manche sind z.B. im be_style Addon gelagert, wie z.B. das exzellente jquery_ui Plugin von Joachim Dörr oder das exzellente rex_codemirror von jdlx . Die Lagerung im be_style Addon finde ich aber nicht so schön, da ja hier eigentlich nur CSS Geschichten reinkommen sollten bzw. Skins (wenn ich die Funktion des Addons richtig verstanden habe). Desweiteren gibt es beim be_style Addon bis dato kein Addon-Page im Backend, so dass auch die Plugins auch keine Möglichkeit haben dort z.B. eine Einstellungsseite anzuzeigen.

Andere Addons wiederum, wie z.B. das slice_status Addon sind eigentlich so mini, das Sie zum einen keine Page im Backend brauchen und zum anderen aber irgendwo herrenlos in der Addonverwaltung vergammeln

Idee:
Ein Addon welches als Container für Plugins dient, die das Backend erweitern/ergänzen bzw. Funktionalität beisteuern. Das Addon macht an sich nicht viel, ausser eine Übersichtsseite über alle Plugins anzuzeigen (inkl. Kurzbeschreibung). Desweiteren kann jedes Plugin seine eigene Page unterhalb des Addons bekommen. Der Screenshot zeigt ganz gut was ich meine:
https://www.dropbox.com/s/4i47xxmu8gyok ... nsions.png

Mögliche Plugins
- [rexdude] slice_status (gibts ja als Addon, hier nun als Plugin)
- [rexdude] cat_art_name_sync (Synchronisiert autom. Artikel Name mit Kategoriename bei Änderung)
- [rexdude] ...paar mehr sind noch in der Entwicklung/Planung
- [jdlx] rex_codemirror (mit Einstellungspage statt config.inc.php gefummel)
- [jdlx] harvesthq_chosen
- [jdlx] rex_select2
- [jdlx] markitup (?)
- [joachim] jquery_ui (hier mit Einstellungspage, z.B. für Skinauswahl )
- [joachim] mploading_image

Mögliche Namen für das Addon
- Backend Erweiterungen [be_extensions]
- Backend Modifications [be_mod]
- Backend Gadgets [be_gadgets]
- Rex Mini Extensions [rex_mini_extensions]
- RexExtensions [rex_extensions]
- Rextensions [rextensions]

Weitere Besonderheiten
- Die GitHub Seite des Addons enthält auf der Übersichtsseite (README.md) eine Auflistung aller verfügbarer Plugins der verschiedenen Programmierer inkl. Download/GitHub-Link.

Was mein ihr? Macht das Addon sinn? Wären die genannten be_style Plugins in so einem Addon nicht besser aufgehoben? Meinungen, Kommentare, Ideen, weitere mögliche Plugins? Ein Favorit für den Addonnamen?

[Ingo]

Letztendlich möchtest du ein zweites "be_style" Addon mit anderem Namen und einer Eingabemaske pro Plugin machen. Ich hatte irgendwann über genau so etwas auch kurz nachgedacht, mich aber dagegen entschieden. Man würde thematisch zusammengehörige Plugins auf zwei Addons verteilen, ich hab sie lieber in einem. Falls überhaupt mal etwas an den config-Einstellungen der Plugins gemacht werden muss, mache ich das lieber direkt über den Editor in den jeweiligen config-Dateien.

[jdlx]

Ingo hats schon angesprochen.. es gibt nen Grund warum viele/die meisten solcher Plugins für be_style gestrickt werden: be_style ist halt schon da.. immer.. automatisch. Faktisch wäre es am sinnvollsten be_style bezügl. der genannten features aufzubohren. Sprich ein Plugin-Subnavi Konzept, etc.

Ein Addone das in die Richtung geht gibts auch schon.. Joachims Addcode.. dem hatte ich vor ner Weile das Plugin Konzept (Navi, simple Forms & Hilfe) aus dem ImageManager EP spendiert. Aber auch für das Addon gilt: es ist 3rd Party und eben nicht ad hoc schonmal da..

[RexDude]

@Ingo: Hey, danke für den ersten Kommenar!

Man würde thematisch zusammengehörige Plugins auf zwei Addons verteilen, ich hab sie lieber in einem.

Also ich sehe hier 2 thematisch unterschiedliche Geschichten: Skins und Plugins die zusätzl. Funktionalität für dasd Backend bereitstellen. Gerade habe ich auch ins be_style Plugin geschaut: dort wird automatisch für jedes Plugin eine CSS-Datei eingebunden, egal ob sie da ist oder nicht (z.B. "../files/addons/be_style/plugins/rex_codemirror/css_main.css"). Das deutet auch auf die Intention des Addons hin, ab vielleicht sagen die Herr Autoren auch noch was dazu.

Falls überhaupt mal etwas an den config-Einstellungen der Plugins gemacht werden muss, mache ich das lieber direkt über den Editor in den jeweiligen config-Dateien.

Das gilt vielleicht für dich, aber was ist mit den ganzen Leuten die weder Bock haben in den einzelnen Konfiguartionsdateien der Plugins/Addons herumzupfuschen noch das Know-How dazu besitzen?

[RexDude]

Faktisch wäre es am sinnvollsten be_style bezügl. der genannten features aufzubohren.

Wäre ne Idee mit der ich mich evtl. anfreunden könnte. Aber hier wäre zuerst wichtig zu klären was die genaue Intention des Addons ist und was die Autoren meinen.

Ein Addone das in die Richtung geht gibts auch schon.. Joachims Addcode.. dem hatte ich vor ner Weile das Plugin Konzept (Navi, simple Forms & Hilfe) aus dem ImageManager EP spendiert. Aber auch für das Addon gilt: es ist 3rd Party und eben nicht ad hoc schonmal da..

Siehst du genau das meine ich: noch so ein Addon von dem ich bis dato quasi nix wusste und ich auch die Plugins nicht kenne. In meinem Post ging es nicht nur um das Addon sonder halt um die Frage "Wie kann man das alles mal unter einen Hut bringen? ink. zentrale Anlaufstelle für alle diese netten Plugins" Das be_settings ist ja z.B. auch noch da

[Ingo]

Gerade habe ich auch ins be_style Plugin geschaut: dort wird automatisch für jedes Plugin eine CSS-Datei eingebunden, egal ob sie da ist oder nicht (z.B. "../files/addons/be_style/plugins/rex_codemirror/css_main.css"). Das deutet auch auf die Intention des Addons hin, ab vielleicht sagen die Herr Autoren auch noch was dazu.

https://github.com/redaxo/redaxo4/pull/59
Sicherlich war das be_style Addon initial nicht dafür gedacht, aber es spricht nichts dagegen es als Andockstation für Backend-Plugins aller Art zu nehmen. Code ist Code.

Das gilt vielleicht für dich, aber was ist mit den ganzen Leuten die weder Bock haben in den einzelnen Konfiguartionsdateien der Plugins/Addons herumzupfuschen noch das Know-How dazu besitzen?

Diese Backend Plugins sind imho allesamt was für Entwickler. Als Entwickler sollte man zum "herumpfuschen" in der Lage sein. Ich sehe auch in deiner Liste von Beispielen nichts, was Konfiguration erfordern würde und für Nicht-Entwickler interessant ist.

Siehst du genau das meine ich: noch so ein Addon von dem ich bis dato quasi nix wusste und ich auch die Plugins nicht kenne. In meinem Post ging es nicht nur um das Addon sonder halt um die Frage "Wie kann man das alles mal unter einen Hut bringen?

Das Problem wirst du nicht durch ein Addon lösen können. Wenn es dir generell um die schlechte Auffindbarkeit und Zerstreutheit potenziell nützlicher Addons/Plugins/Module etc. geht: die sinnvolle Lösung für dieses Problem kann nur ein zentrales Register auf redaxo.org sein. Verbesserungsvorschläge dafür den Downloadbereich gibt es ja - man müsste sie nur umsetzen.

[RexDude]

Sicherlich war das be_style Addon initial nicht dafür gedacht, aber es spricht nichts dagegen es als Andockstation für Backend-Plugins aller Art zu nehmen. Code ist Code.

Sorry, kann deine Einstellung überhaupt nicht teilen. Das be_style als Abladestation für grundsätzlich alle Arten von Plugins zu nehmen geht für mich gar nicht. Und dein Pull Request ist für mich nicht optimal: 1.Sollte man mehrfach vorkommende Strings in eine Variable auslagern. 2. Wäre es aus meiner Sicht sinnvoller gewesen zu prüfen in wie weit eine automatische CSS Inkludierung überhaupt noch Sinn macht und sie sonst ggf. enfernen. Aber so ist es halt wenn man ein Addon für Zwecke zurecht biegen will für die es nicht gedacht war.

Diese Backend Plugins sind imho allesamt was für Entwickler. Als Entwickler sollte man zum "herumpfuschen" in der Lage sein.

Weisst du, bei meinen Überlegungen versuche ich alle Interessengruppen mit einzubeziehen. Sowohl Entwickler die komfortabel Einstellungen in den Plugins tätigen können, als auch REDAXO-Neulinge die gerade am ausprobieren sind und an Einstellungen herumspielen als auch die Grafiker/Redakteure/etc. mit geringen Programmierkentnissen die sich freuen Ihr Backend etwas aufpimpen und einstellen zu können. Deine Aussage, soche Dinge wären sowieso nur für Entwickler geht für mich gar nicht und entspricht nicht meiner erfahrbaren Realität. Und wie soll denn mit so einer Einstellung REDAXO einer größeren Interessengruppe je schmackhaft gemacht werden?

Ich sehe auch in deiner Liste von Beispielen nichts, was Konfiguration erfordern würde und für Nicht-Entwickler interessant ist.

Um das zu sehen musst du halt mal in die Plugins rein schauen Zum Beispiel: rex_codemirror! Hat bereits einige Einstellungen in der config.inc.php. Ausserdem wachsen Plugins/Addons ja. Als ob die jetzt auf dem Stand bleiben und keine einzige Einstellungsmöglichkeit je dazu kommen wird/darf. Oder schau dir das Markitup Addon an. Zu Beginn gar keine bis ganz wenige Einstellungsmöglichkeiten im Backend wenn ich das richtig in Erinnerung habe. Mittlerweile kann auch ein "Nicht-Entwickler" sein Markitup zusammenklicken was ich ziemlich nice finde.

[jdlx]

Man sollte an der Stelle auch einen Fakt nicht vergessen:
Wir reden hier von r4, d.h. einer Version die demnächst abgelöst wird. Will sagen: die Diskussion und welche Schlüße man daraus ziehen mag ist sicherlich sinnvoll, aber es zu diesem Zeitpunkt noch in konkreten r4 Code münden lassen zu wollen evtl. eher nicht.. Stichwort sinnvoller Einsatz beschränkter Resourcen. Wenn, dann sollte man code-wise eine leichte Portierbarkeit für r5 im Auge behalten.

Was die Distribution angeht: die Schwachpunkte rex.org seitig sind bekannt, dito was es bräuchte um hier Abhilfe zu schaffen.. gleichwohl gilt auch hier: gute Ideen wie Sand am Meer, aber die Resourcen geben nur so und soviel her.

Ich persönlich bin was die Distribution angeht inzwischen ziemlich nüchtern.. in dem Sinne das ich halt Zeug baue, bei Github einstelle und ein paar Interessierte davon wissen lasse. Werbetrommel im Forum rühren und auf feedback/Mitarbeit durch die Community zu hoffen ist meiner Erfahrung nach verlorene Liebesmüh: Selbst zu RexSEO - das ich mal als eines der 3rd Party Addons bezeichnen möchte welches in fast jedem kompatiblen rex installiert sein dürfte - bekam ich auf egal welche Mitteilungen/Infos hier im Forum keinen nennenswertes feedback.

[Ingo]

Aber so ist es halt wenn man ein Addon für Zwecke zurecht biegen will für die es nicht gedacht war.
... Ausserdem wachsen Plugins/Addons ja. Als ob die jetzt auf dem Stand bleiben und keine einzige Einstellungsmöglichkeit je dazu kommen wird/darf.

dann betrachte das be_style Addon doch einfach als wachsend. Gegen einen Pull-Request mit dir sinnig erscheinenden Änderungen wird keiner was haben - mir reichte es, dass nicht mehr automatisch nicht existente CSS Dateien referenziert werden.

Deine Aussage, soche Dinge wären sowieso nur für Entwickler geht für mich gar nicht und entspricht nicht meiner erfahrbaren Realität. Und wie soll denn mit so einer Einstellung REDAXO einer größeren Interessengruppe je schmackhaft gemacht werden?

Wie interessant für Redaxo für eine "größere Interessengruppe" ist, hängt nicht mit meiner Einstellung zusammen - und meine Einstellung ist sicher nicht die aller Redaxo Nutzer. Ich schätze Redaxo in seiner momentanen Form (nicht nur den Code, sondern auch das Drumherum inkl. dieses Forums) als ein CMS für Entwickler oder zumindest ambitionierte und lernbereite nicht-Entwickler ein. Ändern würde das nicht ein zusätzliches Addon auf Github (das man ja auch erst kennen/ finden) muss, sondern eine bessere Informationsarchitektur auf redaxo.org.

Um das zu sehen musst du halt mal in die Plugins rein schauen Zum Beispiel: rex_codemirror! Hat bereits einige Einstellungen in der config.inc.php.

Und die sind durchaus überschaubar. Imho sollte, wer im Life-System kritische Code-Blöcken editiert, auch die folgenden settings in der config verstehen:

Code: Alles auswählen

$REX[$mypage]['settings'] = array(
  'theme' =>'jdlx',
  'keys' => array(
    'enter_fullscreen' => 'F11',
    'leave_fullscreen' => 'Esc',
    ),
  // WHITELIST: ENABLED BACKEND PAGES
  'enabled_pages' => array(
      array('page'=>'content'),
      array('page'=>'template'),
      array('page'=>'module'),
      array('page'=>'xform', 'subpage'=>'email'),
      array('page'=>'xform', 'subpage'=>'form_templates'),
    ),
  // BLACKLIST: NO CODEMIRROR TEXTAREA CLASS NAMES
  'disabled_textarea_classes' => array(
    'no-codemirror','markitup'
    ),
  'foldmode' =>'tagRangeFinder', // @html: tagRangeFinder, @php: braceRangeFinder
  );
 

Oder schau dir das Markitup Addon an. Zu Beginn gar keine bis ganz wenige Einstellungsmöglichkeiten im Backend wenn ich das richtig in Erinnerung habe. Mittlerweile kann auch ein "Nicht-Entwickler" sein Markitup zusammenklicken was ich ziemlich nice finde.

Deshalb ist es ja auch ein eigenes Addon und kein Plugin.

Es wäre schön, wenn Redaxo populärer wäre. Wenn du glaubst, dass das von dir geplante Addon dabei hilft, mach es. Ich meine eben nur, dass der Aufwand das Ergebnis nicht wert ist und dass man an anderer Stelle ansetzen sollte.

[Ingo]

Selbst zu RexSEO - das ich mal als eines der 3rd Party Addons bezeichnen möchte welches in fast jedem kompatiblen rex installiert sein dürfte - bekam ich auf egal welche Mitteilungen/Infos hier im Forum keinen nennenswertes feedback.

Du musst mehr Fehler einbauen

[Oliver.Kreischer]

<ot>
Nur mal am Rande... REXseo ist schon seit langen eines meiner Hauptargumente für Redaxo!

Danke dafür (an alle).
</ot>

LG
Oliver

[RexDude]

Moinsen alle zusammen!

Ich habe mir jetzt kurzerhand überlegt das Addon zu realisieren, weil a) ich überzeugt von der Idee bin und b) ich einfach Bock drauf hatte

Es werden für den Anfang 7 Plugins mitgeliefert, die meisten mit einer Einstellungsseite Ich habe mir erlaubt das Plugin rex_codemirror von jdlx und das Plugin jquery_ui von Joachim Dörr einer Geschlechtsumwandlung zu unterziehen und dem Addon beizulegen. Die Autoren mögen es mir verzeihen

So sieht das ganze jetzt aus:
https://www.dropbox.com/s/4i47xxmu8gyok ... nsions.png

Und so die Addon-Verwaltung (be_style für reine Style/Skin Angelegenheiten, der Rest kommt in be_extensions):
https://www.dropbox.com/s/pp5xmecyocneb ... sions2.png

Download:
http://www.redaxo.org/de/download/addons/?addon_id=1045

GitHub Seite mit weiteren Informationen:
https://github.com/RexDude/be_extensions

Der Aufruf aus dem ersten Post gilt allerdings nach wie vor

Übrigens: Man sollte das ganze jetzt mal als umgesetzte Idee/Prototyp betrachten. Ob vielleicht be_style die Funktionalität später spendiert bekommt, oder es in ne ganz andere Richtung geht sieht man dann...

[Gregor.Harlan]

Ich finde die Idee eigentlich ganz gut, mit be_settings habe ich ja etwas ähnliches befolgt. Da ist die Entwicklung aber schon recht lange eingeschlafen, auch wenn es wohl noch mit 4.4.1 funktioniert. Eine Funktion daraus (cat-art-sync) hast du bei dir ja auch sogar schon drin, daher werde ich dann be_settings wohl erst recht nicht mehr weiterentwickeln. Es müsste wenn auch mal grunderneuert werden, was du mir ja jetzt quasi abgenommen hast.

Bisschen problematisch finde ich allerdings den Namen, weil der Begriff "Extension" ja eigentlich in Redaxo schon belegt ist (Extensions docken sich an ExtensionPoints an). In R5 gibt es auch die Klasse rex_extension schon, die du nun auch in deinem Addon hast. Daher würde ich zumindest die Klasse umbenennen in "rex_be_extension" oder so.
So ganz optimal finde ich das dann aber auch immer noch nicht, denn es wird durch das Addon ein bisschen suggeriert, es gebe neben "Addons" und "Plugins" nun noch ein weiteres Paketformat für Erweiterungen, eben die "Extensions", wobei es ja eigentlich auch nur Plugins sind.
Eine Idee für einen vielleicht besseren Namen habe ich aber gerade leider auch nicht…

[jdlx]

Backend Utilities .. evtl. sogar Backend weglassen.. Rex Utilities
(ein guter deutscher Begriff für Utilities fällt mir nicht ein..)

[frag-seb]

Ideen ... Betriebsmittel, Hilfsmittel, Instrument

[jdlx]

..womit die Daseinsberechtigung von Anglizismen erbracht wäre. ;)

[RexDude]

@gregor: Hallo Gregor! Vielen Dank für dein Feedback! Bin froh, dass du die Idee schon mal gut findest, weil es ja doch sehr ähnlich zu deinem be_settings ist. Aber ich habe halt auch gesehen, dass du es länger nicht mehr upgedated hast und auch der Name war mir nicht ganz stimmig. Deshalb hab ich jetzt einfach mal drauf los-gehackt Ich hoffe ich habe dir dein "Baby" jetzt aber nicht abgenommen mit der Aktion? Aber wenn es bei so einem Addon bleiben sollte, könnte ich mir die Plugins aus dem be_settings sehr gut drin vorstellen Damit würde man schon auf über 15 mögliche Plugins kommen

Das es in R5 die Klasse "rex_extension" bereits gibt war mir leider nicht bewusst. Wie wäre es denn mit "rex_plugin" und "rex_plugin_manager"? Gibts die schon? Der Vorteil hier: man hätte den Begriff "extensions" nur noch im Addonamen (also Übersetzung zu "Erweiterungen") und auch nur mit "be" kombiniert und man könnte die beiden Klassen auch für andere Addons verweden die vielleicht mal solche Übersichtseiten für Plugins generieren wollen.

@jdlx: Utilities ist auch ganz nice, aber man kanns halt net gut eindeutschen und wer weiss ob alle was mit dem Begriff überhaupt anfangen können "be_" davor fänd ich schon ganz gut, wenn man sich halt drauf einigt, dass das Addon für Plugins da sein soll die das Backend erweiter/ergänzen etc. Sonst kann man praktisch alles reinhauen, und dann könnte man es auch "rex_dumpster" nennen

[Gregor.Harlan]

Ich hoffe ich habe dir dein "Baby" jetzt aber nicht abgenommen mit der Aktion?

Keine Sorge, ich habe keine tiefere Verbundenheit zu dem Addon, und bin dankbar wenn jemand anderes da mal was neues macht!

Wie wäre es denn mit "rex_plugin" und "rex_plugin_manager"? Gibts die schon?

Beide Klassen gibt es exakt so in R5 , in R4 heißen sie noch OOPlugin und rex_pluginManager.

Utilities finde ich auch ganz gut, sehe es aber auch so, dass man das Addon auf Backend-Dinge beschränken sollte, und dies am besten auch im Namen schon deutlich wird.

[jdlx]

Yo, ne Eingrenzung auf Backend da spricht nichts dagegen.. hinsichtlich Eindeutschung: klar ginge auch "Administrationsbereichs-Hilfsprogramme" oder so, aber phonetisch is das so elegant wie Steuerbürger oder dergleichen.. insofern mein ganz persönlicher vote: Backend Utilities ;)

[RexDude]

Ideen ... Betriebsmittel, Hilfsmittel, Instrument

ganau: Backend Betriebsmittel aka be_betriebsmittel + rex_betriebsmittel und rex_betriebsmittel_manager



@jdlx: Von Backend Utilities bin ich noch nicht 100% überzeugt Unter Utilities verstehe ich Werkzeuge und diese Plugins sind aber da um das Backend zu erweitern/ergänzen. Also keine Tools im eigentlichen sinne sondern halt Erweiterungen

Das deutsche "Backend Erweiterungen" ist nachwie vor ein Favorit für mich + be_extensions und nun rex_plugin_wrapper und rex_plugin_wrapper_manager zwecks R5 und möglicher Benutzung auch für andere Addons. Allerdings könnten die Klassen auch grundsätzlich überflüssig werden, weil ich gerade in OOPlugin gesehen habe, dass es die Methoden get/setProperty ja gibt mit der man Felder wie ne Description ja vermutlich nachrüsten kann. Und sogar getAvailablePlugins() für die Übersichtsseite...hätt ich mal vorher in die Doku geschaut

mir kam außerdem noch be_essentials, be_additions, be_central (@jdlx: von jquery_central) in den Sinn.

Was ist eigentlich mit be_style? Ist das damit vom Tisch? Der Vorteil wäre halt wie jdlx meinte: es ist schon da und man könnte sonst auch die Plugin-Übersichtsseite dort integrieren. Aber:Ein Plugin wie das cat_art_name_sync würde da halt schlicht und einfach nicht reinpassen, weil es nix mit style zu tun hat sondern nur Funktionalität nachrüstet. Und man hätte halt Skins plus der "Extensions" in ein Addon gefercht.

Und hier wäre auch noch was für R5 zu berücksichtigen: https://github.com/redaxo/redaxo/issues/177

Und hier wird dem Herrn Blum ein Feature aufgedrückt, dass man prinzipiell auch über ein Plugin lösen könnte:
https://github.com/redaxo/redaxo4/pull/ ... t-12037809

Puh, ein sehr vielschichtiges Thema...

[jdlx]

Obacht.. nicht verzetteln! ;)

* Fakt ist: der Name ist - sofern nicht zu blöd/abwegig - letztendlich wurscht.
* be_style aufzubohren oder durch einen weiter gefächterten Nachfolger zu ersetzen wäre imho eigentlich der Weg der Wahl.. Teil des Core/default DL ist hier imho das zentrale Feature.. allein: da müssten Jan/Gregor/Markus erstmal ihr Servus unter die Idee setzen, sonst DOA.

Zu jquery_central: die Idee/Wunsch gärt in mir schon seit Jahren.. aber: das ist ein - wenn man es amtlich machen will - so großes Faß, daß ich da letztlich die FInger von gelassen hab. Es ist eine Sache die beiden großen Kernkomponenten - jQuery selbst und jQuery_UI - mit Versions-Auswahl, frontend/backend include, usw. anzubieten (von einer Anforderungs-API mal ganz zu schweigen).. eine ganz andere Nummer wären weitere jQuery plugins.. die gibt es zum einen wie Sand am Meer, zum anderen kommen sie und gehen.. keinerlei Konstanz, es gibt keine zentrale Stelle für einen Bezug, usw.. gutes Beispiel der Problematik: rex_chosen hab ich glaub ich vor grad mal nem halben Jahr gestrickt.. zack, gibts select2.. welches chosen zum Teil ablöst, aber auch nicht ganz.. will sagen: ein rat race ohne Ende.
Bottomline: schöne Grundidee, im RL ein Faß ohne Boden das man besser zu läßt..

[Gregor.Harlan]

Allerdings könnten die Klassen auch grundsätzlich überflüssig werden, weil ich gerade in OOPlugin gesehen habe, dass es die Methoden get/setProperty ja gibt mit der man Felder wie ne Description ja vermutlich nachrüsten kann.

Angenommen das Plugin "foo" setzt das hier in der config.inc:

Code: Alles auswählen

$REX['ADDON']['description']['foo'] = 'Description'; 

Dann kannst du die so abfragen:

Code: Alles auswählen

$description = OOPlugin::getProperty('be_extensions', 'foo', 'description'); 

In der Plugin-config.inc selbst funktioniert OOPlugin aber nicht (aufgrund des Verschiebemechanismusses der Pluginproperties).

Bzgl. be_style: Ich würde es schon so lassen, dass das Addon nur für das Backenddesign zuständig ist. So etwas wie chosen passt da vielleicht noch rein, es passt aber ebenso in be_extensions. Aber sowas wie cat_art_name_sync passt (wie du schon sagst) sicherlich nicht zu be_style.

[RexDude]

@Gregor: Vielen Dank für den Hinweis. Überlege gerade ob ich nun die Klassen entfernen soll oder sie doch einfach in rex_plugin_wrapper und rex_plugin_wrapper_manager umbenenne, da es doch sehr viel angenehmeren Code gibt und man ein Plugin in seiner config.inc.php mit einem Zweizeiler registrieren kann.

Sonst sieht es halt so aus:

Code: Alles auswählen

// register plugin
$REX['ADDON']['page']['cat_art_name_sync'] = 'Cat-Art Name Sync';
$REX['ADDON']['version']['cat_art_name_sync'] = '1.0.0';
$REX['ADDON']['author']['cat_art_name_sync'] = '';
$REX['ADDON']['supportpage']['cat_art_name_sync'] = 'forum.redaxo.de';
$REX['ADDON']['description']['cat_art_name_sync'] = $I18N->msg('cat_art_name_sync_description');
    
// add sub page
$REX['ADDON']['be_extensions']['SUBPAGES'][] = array('plugin.cat_art_name_sync', $REX['ADDON']['page']['cat_art_name_sync']);

Diese Schreibweise wäre dafür halt "vertrauter".

Was meinst du? Auch in Hinblick auf R5?

[Gregor.Harlan]

Für R4 kann ich es nicht so ganz einschätzen, ich habe mir jetzt auch noch nicht so genau angeschaut, was deine Klassen im Einzelnen machen etc.
Aber in R5 würde ich auf jeden Fall empfehlen, soweit es geht die vorhandene Addon-/Plugin-Api zu verwenden, die ist aus meiner Sicht auch deutlich angenehmer als in R4.

[RexDude]

Für R4 kann ich es nicht so ganz einschätzen, ich habe mir jetzt auch noch nicht so genau angeschaut, was deine Klassen im Einzelnen machen etc.

Hier wirds erklärt:
https://github.com/RexDude/be_extension ... -interface

Und das hier ist die Wrapper Funktionalität:
https://github.com/RexDude/be_extension ... er.inc.php