Nützliche Entwickler-Tools

Hi,

ich riskiere jetzt meine zweistellige Beitragszahl, weil mir einer der Entwicklung Hoffnung gemacht hat, willig zu sein, meinen Wunsch nach brauchbaren Entwickler-Tools umsetzen zu wollen.

Quote from Alexander Ebert

Dann möchte ich dich bitten, dies entsprechend im Vorschlagsforum zur Sprache zu bringen

Wo soll ich anfangen...?

Also das Problem ist meiner Meinung nach noch immer, dass das Gebilde, das sich WCF nennt, zu schlecht dokumentiert ist. Man muss sich alles irgendwo zusammensuchen, meist gibt es die Dokumentation nicht einmal von WoltLab direkt, es gibt kaum einen Einstiegspunkt, wo man mal anfangen könnte, sich an das System zu gewöhnen, man darf alles selbst zusammenpacken und die XML-Dateien noch selbst schreiben. Wah!

Meine Vorschläge wären daher:

Plugins (oder mehr) in einem UI

Wie wäre es, wenn es, wenn man für alle benötigten Schritte auf dem Weg zum eigenen Plugin (oder langfristig zur ganzen Endanwendung) an die Hand genommen wird und ein UI bekommt, wo ein paar Fragen beantwortet werden und schon steht wenigstens das Gerücht eines Plugins?

Das kenne ich vom XenForo und vorher vBulletin. Da ist der Workflow folgendermaßen: Debug-Modus an, neues Plugin erstellen, Name, Identifier, Version und was sonst noch so benötigt wird. Speichern.

Nun habe ich bei so gut wie allen Elementen im ACP die Möglichkeit, am "MASTER" zu arbeiten - MASTER-Sprache, MASTER-Templates, MASTER-Einstellungen, MASTER-Alles. Ich kann dort direkt auswählen, wozu mein neues Element gehört, also meinem Plugin zum Beispiel.

Einfaches Beispiel: Ich erstelle eine neue Einstellung, z.B. "Soll $meineFunktion aktiviert sein? [bool]" - und weise diese Einstellung meinem Plugin zu. Die Einstellung hat natürlich eine Variable oder eine Konstante oder was auch immer zur Folge, die dann im System verfügbar ist. Die Texte legen natürlich auch gleich eine Sprachvariable (im MASTER) an, die ebenfalls zu meinem Plugin gehören. Später kann ich dann mein Plugin ersetzen. Aber dazu kommen wir noch.

Also habe ich mir jetzt schon die gesamte Action im ACP zusammengeklickt, ohne einen Texteditor überhaupt geöffnet zu haben.

Inline-Doku und Hilfestellung bei den Plugin-Aktivierungen

Ich gebe zu, ich habe keine Ahnung, wie ihr das alles nennt. Bei WordPress sind es Hooks, bei XenForo glaub ich auch. Aber XF funktioniert ohnehin anders, da kann ich so gut wie jede Klasse, die es gibt, mit einer eigenen überschreiben oder erweitern. Auf jeden Fall muss ja wahrscheinlich auch beim WSC irgendwo hinterlegt werden, DASS mein Plugin irgendwas laden wird, richtig? XenForo bietet hier ein UI, wo ich mir solche Events aussuchen kann. Die Inline-Doku erklärt mir dann, wie der Construktor aussehen muss, was meine Klasse erweitern muss usw, damit alles funktioniert.

-- Das ist jetzt die Stelle, an der ich meinen Code schreibe und das erste Mal, dass ich einen Editor öffnen muss --

Im Laufe der Zeit wird es Templates geben, Templatepatches(?) (<-- gerne auch hierfür ein UI, bei XF/vB ist das als TMS bekannt) und Sprachvariablen. Ganz am Ende hätte ich die Möglichkeit, mit einem neuen Menüpunkt, mein Plugin zu übersetzen, der Inhalt der MASTERLANGUAGE ist gesetzt und alle anderen bekomme ich angeboten, z.B. Deutsch, Französisch usw.

Nun landen die Dateien für mein Plugin irgendwo - ich habe mich so tiefgründig nicht damit befasst, aber wahrscheinlich muss man für sein eigenes Plugin keinen extra Ordner anlegen? Also wenn man das müsste, wäre das ja recht praktisch, weil dann alles auf einem Haufen ist, andernfalls müsste man oben beschriebenem UI sagen, welche Dateien dazugehören. Aber das musste man wohl auch jetzt schon, weil sonst würde die Deinstallation ja nicht funktionieren, richtig?

Also sagen wir, das System hat sich irgendwo notiert, welche Dateien zu meinem Plugin gehören. Denn das bringt uns zum abschließenden Schritt...

Export des Plugins

Ungefähr da, wo ich mein Plugin angelegt habe, gibt es einen neuen Export-Button. Der sucht im System alle Elemente, die mit meinem Plugin assoziiert sind und bastelt daraus die notwendigen XML-Dateien und am Ende das passende TAR-File, damit ich mein Plugin weitergeben kann.

Dann habe ich keine einzige XML-Datei bearbeitet und habe einen Workflow, der auch euch als Entwickler des WSC und der einzelnen Endanwendungen weiterhilft. Weil ihr euch dann daraus auch eine defaults exportieren könnt, der dann für den Core ist.

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

Ihr hättet dann den Vorteil, dass das gesamte System einfacher zu erweitern wäre und die Berührungsängste schwinden. Wenn es eine Inline-Doku gibt, brauchts dann auch keine externe mehr auf der Webseite, die chronisch veraltet ist, denn sobald neue Events dazukommen, muss man die Templates ja ohnehin erweitern.

Langfristig würde das das System zugänglicher und bequemer machen und dann auch den Plugin-Store weiter füllen. Weil ich kann mir gut vorstellen, dass ich nicht alleine damit bin, Abstand von der Erweiterung des Systems zu nehmen, weil ich schlichtweg nicht die Zeit dafür habe, mir selbst anzueignen, was wohin muss. Wenn man kaum was falsch machen kann, würden es vermutlich auch mehr probieren.

Und deshalb wünsche ich mir so ein umfassendes Entwickler-System.

Wer bis hier her gelesen hat, dem danke ich recht herzlich