sorry, nicht verstanden.

die entwicklerin des tools schreibt weiterhin ein tool und schreibt die gesamte spezifikation an eine stelle (statt wie bisher hier Getopt, dort das pod, woanders der aufruf von pod2usage und mit viel schweiss und tränen noch eine shell completion).
das framework dafür schreibe ich.

vielleicht magst du genauer erklären, was du meinst. mir ist auch nicht klar, ob du dir mein Beispiel angeschaut hast oder nicht.

Ja, genau solche Fragen brauche ich =)

Derzeit schreibt man den kompletten Code in eine Klasse. Möchte man das auf mehrere Klassen aufteilen, müsste man delegieren.

Der Plan ist aber, dass man die Kommandos wie bei den App-Modulen auf Klassen aufteilen kann. Aber optional, denn es gibt Fälle, wo man das nicht will und wo es sehr hinderlich wäre. Zeige ich vielleicht demnächst bei meinem Anwendungsfall, der mich dazu gebracht hat. Der ist aber noch nicht reif für die Öffentlichkeit.

Schreibt man jetzt ein Plugin, dann hat das Plugin eine eigene Spezifikation, die dann on-the-fly zu der Haupt-Spezifikation hinzugefügt würde.
Man kann übrigens auch statt einer Datei das YAML beispielsweise in den __DATA__ Teil des Moduls packen.

Wie das ganze genau aussehen wird, muss ich mir jedenfalls noch überlegen.
Vielleicht einfach statt des Eintrags op: subcmd_name ein op: MyApp::subcmd_name::main oder ein globaler Eintrag, der das automatisch macht.

Eine Frage noch: wie erkennt die Haupt-App bei App::Cmd, dass ein Plugin verfügbar ist? Wird das automatisch gemacht, indem das Modulverzeichnis durchsucht wird, oder gibt man das irgendwo an?
Last edited: 2015-12-01 19:36:02 +0100 (CET)