Abhängigkeiten und EAs

  • Hallo,
    das Grundpaket meines Livetickers-Plugins ist ein "com.woltlab.wcf.data.page" Plugin und wird somit auch in anderen EAs angezeigt. Jetzt hat mich eine Pluginrezension (#2) auf folgendes aufmerksam gemacht: Die Zusatzpakete für mein Plugin, die unteranderem ein "com.woltlab.wbb" Plugin sind verursachen nun das Problem, dass sie bei anderen EAs (die ja nur vom WCF abhängig sind) nicht korrekt angezeigt werden. Sprachvariablen werden dort beispielsweise nicht umgewandelt.
    Ich sehe gerade keine direkte Möglichkeit, diesen Fehler zu beheben außer mein Grundpaket des Plugins abhängig vom WBB zu machen..? Jemand eine andere Idee?

    Vielen Dank!

    Edit: Ich merke gerade, dass der plugin-tag beim Grundpaket und beim optionalen User-Paket auf com.woltlab.wcf steht - was natürlich falsch ist.
    Könnte sich jemand (falls Zeit und Lust vorhanden) mal bitte die Abhängigkeiten aller Pakete anschauen? Ich glaube ich habe da allgemein ein Denkfehler...

  • Hallo,
    das Grundpaket meines Livetickers-Plugins ist ein "com.woltlab.wcf.data.page" Plugin und wird somit auch in anderen EAs angezeigt. Jetzt hat mich eine Pluginrezension (#2) auf folgendes aufmerksam gemacht: Die Zusatzpakete für mein Plugin, die unteranderem ein "com.woltlab.wbb" Plugin sind verursachen nun das Problem, dass sie bei anderen EAs (die ja nur vom WCF abhängig sind) nicht korrekt angezeigt werden. Sprachvariablen werden dort beispielsweise nicht umgewandelt.
    Ich sehe gerade keine direkte Möglichkeit, diesen Fehler zu beheben außer mein Grundpaket des Plugins abhängig vom WBB zu machen..? Jemand eine andere Idee?

    Vielen Dank!

    Edit: Ich merke gerade, dass der plugin-tag beim Grundpaket und beim optionalen User-Paket auf com.woltlab.wcf steht - was natürlich falsch ist.
    Könnte sich jemand (falls Zeit und Lust vorhanden) mal bitte die Abhängigkeiten aller Pakete anschauen? Ich glaube ich habe da allgemein ein Denkfehler...


    DIe Lösung nennst du doch schon selber. Deine Zusatzpakete können gar nicht in anderen EAs dargestellt werden, da sie nur für das WBB sind. Allein dein Grundpaket ist für alle EAs geeignet. Wenn du jetzt dein Grundpaket auch vom WBB abhängig machen würdest, dann würde 0% in anderen EAs angezeigt werden, da sie dein Plugin nicht kennen. Im Übrigen hast du hier das Problem, dass dein Grundpaket ein Plugin ist, was immer zu vermeiden ist.

    Insgesamt musst du dir die Abhängigkeiten so vorstellen:

    • Es darf niemals ein Paket ein Plugin von einem anderen Plugin sein.
    • Setze dein Paket als Plugin auf das Grundpaket (sonst. Paket) oder die EA an, die die zu ändernde/erweiternde Funktionalität mitbringt. BBCodes werden nicht im WBB geregelt, also ist ein Plugin für das WBB hier falsch am Platze.
    • Möchtest du ein Basispaket haben, welches für alle EAs gilt, dann mache ein sonstiges Paket, welches kein Plugin ist. Für jede Endanwendung kannst du dann ein eigenes Plugin machen, welches auf dem Grundpaket aufbaut.

    Die Kette der Abhängigkeiten sieht so aus:

    • WCF
    • sonstige Pakete, die nur das WCF brauchen
    • sonstige Pakete, die andere sonst. Pakete brauchen
    • Plugins zu sonst. Paketen
    • EAs, die die sonst. Pakete einbinden durch Abhängigkeiten und damit indirekt deren Plugins
    • Plugins zu EAs, die die EAs direkt erweitern

    Überlege dir für dein Paket also, wo du es einordnen musst, dann sollten auch nicht aufgelöste Sprachvariablen Vergangenheit sein.

  • Setze dein Paket als Plugin auf das Grundpaket (sonst. Paket) oder die EA an, die die zu ändernde/erweiternde Funktionalität mitbringt. BBCodes werden nicht im WBB geregelt, also ist ein Plugin für das WBB hier falsch am Platze.

    Dann müsste ich ja mein Grundpaket auf das sontige Paket com.woltlab.wcf.data.page mit ansetzen? Jedoch sagst du weiter oben, dass ein Grundpaket eigentlich als Plugin zu vermeiden sein soll. Muss der <plugin>-Tag dann komplett weggelassen werden und die Anhängigkeiten meiner Zusatzpakete auf <plugin>de.cwalz.liveticker</plugin> gesetzt werden?

  • Dann müsste ich ja mein Grundpaket auf das sontige Paket com.woltlab.wcf.data.page mit ansetzen? Jedoch sagst du weiter oben, dass ein Grundpaket eigentlich als Plugin zu vermeiden sein soll. Muss der <plugin>-Tag dann komplett weggelassen werden und die Anhängigkeiten meiner Zusatzpakete auf <plugin>de.cwalz.liveticker</plugin> gesetzt werden?


    Kein Plugin Tag.

    Dein Grundpaket muss ein ganz normales Paket (kein Plugin) sein, dass einfach nur com.woltlab.wcf.data.page als Abhängigkeit hat.

    Deine weiteren Pakete machst du dann als Plugins für dein Grundpaket (oder als plugin für eine EA mit abhängigkeit auf dein Grundpaket).

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

  • Okay ich habs nun wie folgt probiert:
    Grundpaket package.xml:

    XML
    <packageinformation>
    		<isunique>1</isunique>
    	</packageinformation>
    
    	<requiredpackages>
    		<requiredpackage minversion="1.1.1">com.woltlab.wcf.data.page</requiredpackage>
    	</requiredpackages>

    Optionales Paket für den Woltlab Calendar package.xml:

    XML
    <packageinformation>
    		<isunique>1</isunique>
    		<plugin>de.cwalz.liveticker</plugin>
    	</packageinformation>
    
    
    	<requiredpackages>
    		<requiredpackage minversion="1.1.1">com.woltlab.wcal.wbb</requiredpackage>
    		<requiredpackage minversion="1.0.0">de.cwalz.liveticker</requiredpackage>
    	</requiredpackages>

    Lediglich bei meinem optionalen Paket für die Neuigkeitenbox sieht die package.xml so aus:

    Und bei meinem optionalen Paket für das Forum (benötigt Themen & Beiträge):

    Hätte ich es wie oben gemacht, gabs immer ein Fatal Error.
    Stimmen die Abhängigkeiten denn so?

  • Mit Abhängigkeit meinst du <requiredpackages>?


    Ich empfehle mal die Lektüre der beiden folgenden Blog-Einträge:
    dtdesign @ woltlab.com: Plugin-Entwicklung: Abhängigkeiten richtig setzen
    Und einen meiner eigenen Beiträge: http://www.tr3kk3r.net/blog/u1-tr3kk3…#profileContent

    Da steht u.a. auch drin welche Arten von Abhängigkeiten es gibt.

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

  • Habe ich bereits und in deinem Beitrag (welcher sehr informativ ist) den Abschnitt mit den Sonstigen Paketen und folgenden Abschnitt gelesen

    Zitat


    Sonstige Pakete, die nur vom WCF abhängig sind, bzw. von Paketen abhängig sind, die selber nur vom WCF abhängig sind, sollten einzigartig, (engl. "unique") sein, d.h. nur einmal installierbar.

    Dann müsste doch folgende package.xml für das Grundpaket so stimmen:

    XML
    <packageinformation>
    		<isunique>1</isunique>
    	</packageinformation>
    
    	<requiredpackages>
    		<requiredpackage minversion="1.1.1">com.woltlab.wcf.data.page</requiredpackage>
    	</requiredpackages>


    ?
    Denn leider werden die Optionen aus dem Plugin nicht im ACP hinzugefügt..

  • Plugins (also ohne <plugin>-Tag) können, soweit ich weiß, solche Dinge nicht zur Verfügung stellen.


    Doch, können sie. Optionen, die in sonstigen Paketen mitgeliefert werden, werden aber erst dann im ACP angezeigt, wenn es auch mind. ein Plugin gibt, welches dieses sonstige Paket benötigt.

    Das sonstige Paket stellt die Optionen zwar zur Verfügung, aber solange kein Plugin da ist, welches das Paket tatsächlich benötigt, werden diese auch nicht angezeigt. Wie Alexander Ebert in seinem Blogeintrag schrieb, sonstige Pakete stellen einen Service zur Verfügung (in diesem Fall halt auch Optionen), aber so lange kein Plugin diesen Service benötigt, wird er halt nicht benutzt.

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

  • Grundpaket:

    Zusatzpaket:

    Auch wenn ich beide installiere, erscheint die Option im ACP nicht. Die Eventlistener von Zusatzpaket funktioniert auch nicht. Sind die Abhängigkeiten noch falsch?

  • Bist du sicher, dass dein User-Zusatzpaket nur vom WCF selber, und von deinem Zusatzpaket abhängig sein soll, und nicht vom Userprofil o.Ä.?

    hast du das ganze mal in einer frischen Installation ausprobiert (in einer älteren kann man schonmal mitgeschleppte Abhängigkeitsfehler haben xD ) ?

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

  • Habe das Board gestern erst neu installiert, gerade weil ich Befürchtungen wegen noch vorhandenen Abhängigkeitsfehlern hatte.

    Ich habe mir nochmals meine ELs im User-Zusatzpaket angeschaut:
    RegisterForm --> com.woltlab.wcf.form.user
    AvatarEditForm --> com.woltlab.wcf.page.user.profile
    SignatureEditForm --> com.woltlab.wcf.form.user.signature

    com.woltlab.wcf.form.user benötigt com.woltlab.wcf.page.user.profile
    -->


    Das WCF habe ich nun rausgeschmissen, da ich ja nicht alle Komponenten benötige?
    Die Optionen werden leider trotzdem noch nicht angezeigt.

    Kann es mit den ELs meines Grundpakets zusammenhängen?
    shouldDisplay@StructuredTemplate
    assignVariables@IndexPage

    Diese benötigen doch eigl. nur com.woltlab.wcf.data.page?

  • Also das WCF musst du zwar nicht explizit als Abhängigkeit angeben, da alle Pakete davon abhängig sind, allerdings ist es nützlich, um eine bestimmte Mindestversion anzugeben.

    Die von dir genannten Pakete erweitern ihrerseits das WCF und benötigen es somit logischerweise auch und nicht umgekehrt. StructuredTemplate gehört zum Templatesystem und ist WCF-Bestandteil (Abhängigkeit zu com.woltlab.wcf). Die IndexPage ist immer EA-abhängig, da nur EAs eine IndexPage haben können (außer du meinst das WCF-ACP). Daher darf in einem Grundpaket, welches die Basis für mehrere EAs bilden soll, niemals ein EL auf eine IndexPage einer EA drinnen sein. Diese IndexPage-ELs packst du dann in ein Extrapaket, welches die jeweilige EA erweitert (<plugin>BezeichnerEA</plugin>) und dein Grundpaket benötigt (Abhängigkeit zu Grundpaket).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!