Unsere Anwendung verfügt über eine Reihe von Widgets, die Vorlagen verwenden, die über eine JSP direkt generiert werden.
Im Front-End-Code sind sie mit dem Dojo / Text-Plugin enthalten. Dadurch wird sichergestellt, dass der Widget-Lebenszyklus erst dann gestartet wird, wenn die Vorlage aufgelöst wurde, und es funktioniert problemlos.
Leider, wenn wir versuchen, unseren Build auszuführen, erhalten wir einen 311 Fehler:
error (311) Fehlende Abhängigkeit. Modul: App / Navigation / NavigationManager; Abhängigkeit: dojo / text! /author/app/templates/NavigationManager-content.html; Error: Fehler: Textressource (/author/app/templates/NavigationManager-content.html/x) fehlt
Ich verstehe, was hier passiert, der Build-Prozess versucht, den String zu internalisieren, aber wenn er danach sucht, kann er ihn nicht finden und markiert ihn als fehlende Abhängigkeit.
Ich sehe hier eine Reihe von Optionen:
Ich habe Hinweise auf die gefunden internStringsSkipList Wert, aber keine der folgenden geholfen:
%Vor%Irgendwelche Vorschläge?
Ich hatte genau das gleiche Problem und nach dem Lesen von vielen Dojo-Dokumentationen und Quellcode kam ich zu dem Schluss, dass es sehr schwierig ist, wenn es fast unmöglich ist. Es gibt jedoch einen sehr einfachen und eleganten Workaround. Aber bevor Sie Ihnen sagen, wie Sie das Problem zuerst lösen, warum zuerst ein Workaround benötigt wird (damit Sie die Lösung an Ihre eigenen Umstände anpassen können):
Laut dem Übersichtsbereich des Dojo-Build-Systems Referenzhandbuch :
[Das Build-System] "entdeckt" eine Menge von Ressourcen und wendet dann eine synchronisierte, geordnete Menge von ressourcenabhängigen Transformationen auf diese Ressourcen an. (...) Wenn eine Ressource entdeckt wird, wird sie mit einem oder mehreren Flags versehen, die dabei helfen, die Rolle dieser Ressource zu identifizieren. (...) Nachdem eine Ressource erkannt und markiert wurde, weist das System eine Reihe von Transformationen zu, die auf diese Ressource angewendet werden sollen.
Kurz gesagt, können alle im laufenden Betrieb generierten Ressourcen nicht vom Build-System erkannt werden, da sie nicht im Dateisystem vorhanden sind. Wenn sie nicht gefunden werden können, können sie nicht markiert werden und keine Transformation kann darauf angewendet werden. Insbesondere wird resourceTags für solche Ressourcen nicht aufgerufen und Sie können sie nicht in die Liste exclude einer Profillayerdefinition einfügen (vergleiche Abschnitt Layer in Erstellen von Builds ).
Übrigens, soweit ich das verstehe, die Dokumentation zu depsScan transform , internStringsSkipList kann nur zum Überspringen von Ressourcen verwendet werden, die in der Legacy-Notation angegeben wurden ( dojo.something , zB dojo.moduleUrl ).
Die Notation dojo/text!/some/url sagt, dass die dojo/text.js -Komponente als Plugin verwendet werden soll. Ich habe diese Notiz in diesem Ticket gefunden:
Jedes AMD-Plugin sollte einen Plugin-Resolver in
util/build/pluginshaben und inutil/build/buildControlDefaultregistriert haben.
Wenn Sie util/build/plugins/text.js (zB auf Github ) überprüfen, Ich sehe, dass der Fehler ausgelöst wird, weil die Abhängigkeit (der Teil nach dojo/text! in moduleInfo gespeichert ist) nicht im Array resources ist:
Und genau deshalb, weil die Ressource während der "Entdeckungsphase" nicht entdeckt werden konnte.
In der schwierigen Lösung, die möglicherweise funktioniert oder nicht, müssten Sie ändern, wie die Umwandlung depsScan funktioniert. Wenn depsScan auf dojo/text!/some/url trifft, ruft es im Grunde den Plugin-Resolver auf, um zu prüfen, ob die Abhängigkeit existiert. Aus der Dokumentation von depsScan :
Sobald alle Abhängigkeiten gefunden sind, stellt die Transformation sicher, dass alle Abhängigkeiten in den erkannten Modulen existieren. Fehlende Abhängigkeiten führen dazu, dass ein Fehler in der Konsole und im Build-Bericht protokolliert wird.
Dies könnte möglich sein, indem transformJobs neu definiert wird, um eine benutzerdefinierte Transformation für depsScan zu enthalten. Siehe util/build/buildControlDefault.js ( auf Github ) und dieser Forenbeitrag für weitere Einblicke.
Erstellen Sie einfach Ihr eigenes Plugin, um die Ressource zu laden. In Ihrem eigenen Plugin wird der Plugin-Resolver nicht registriert (siehe das zweite Problem oben) und alles, was Sie beim Kompilieren bekommen, ist das gefürchtete
warn(224) A plugin dependency was encountered but there was no build-time plugin resolver.
Dies ist mein Beispiel für ein solches Plugin, das eine JSON-Ressource dynamisch lädt:
%Vor% Er verwendet dojo/text erneut und fügt seine benutzerdefinierte Ladefunktion hinzu. Dies ist eine Adaption eines anderen Beispiels, das auf diesem Dojo- veröffentlicht wurde. Toolkit Forenbeitrag . Sie können ihren Code auf JSFiddle sehen.
In meinem Projekt verwende ich das Plugin wie folgt:
%Vor%Ihr Plugin kann die geladene Vorlage einfach zurückgeben, ohne sie als JSON zu analysieren, und solange Sie Ihren benutzerdefinierten Plugin-Resolver nicht angeben (was erwarten würde, dass die Datei physisch auf der Festplatte existiert), wird das Projekt gut kompiliert. p>
Das war nicht dein Problem, aber die häufigste Lösung für diejenigen, die das Problem mit error(311) haben, ist folgendes:
Starten Sie keine Vorlagenpfade mit einem Schrägstrich .
Schlecht:
%Vor%Gut:
%Vor%Ihr Vorlagenpfad ist keine normale, einfache URL. Es ist immer noch Teil des Dojo-Builds. Daher verwenden Sie den Dojo-Buildpfad, um zu der Vorlage zu gelangen.