Ich hole mir den Text aus dem Dokument, lasse es von PPI parsen, hole mir den Packagename, die Subroutinen und baue damit schon die halbe Dokumentation zusammen, so dass ich relativ wenig Arbeit habe...

Das ganze bewegt sich bei mir in Richtung Macros, so dass das am Ende noch mehr kann, wobei man das irgendwann von Templates abkoppeln muss. Aber bis dahin mache ich einen Workaround mit den Templates. Es soll dann in Richtung UML-Diagramme gehen. Deswegen reichen mir die "normalen" Variablen nicht aus, und ich muss den Code anfassen.

das war mir schon klar, ich frag auch um mir einen weg zu überlegen, wie man das auf gesunde weise in den code stöpseln können.

Mit dem "preprocess" kann man schon ziemlich viel machen, da der User ja nicht in dem eingeschränkt ist, was die "preprocess"-Methode machen kann. Für Makros müsste man sich was komplett neues überlegen, was sicherlich nicht so einfach ist. Oder Du bietest so etwas wie eine "API" an, mit der Plugins (die ja Makros sein können) an bestimmte Informationen kommen...

so hab jetzt 2 variablen eingefügt, später kommen siche mehr, zumindest können in templates jetzt auch einfache variablen eigefügt werden mit [$$variablenname].
wenn dir besser syntax einfällt sags mir bitte.

ja aber du siehst das es wirklich nicht die eleganteste lösung ist, ich sehe den nutzen und vieles ähnliches wird sicher wichtig werden. wir sollten uns überlegen was da wirklich passiert denn das hat aus sicht des editors wenig mit templating zu tun und dafür einen ordentlichen mechanismus bereitstellen.

mit plgin API mein ich eher auch wie das plugin dem programm sagt was es brauch (menüeinträge, routine die bei app init ausgeführt werden soll, usw) ich wollte erstmal das sie normale Kephra::irgendwas rufe machen können oder Kephra::CommandList::run_cmd($id). zweiteres ist natürlich etwas sicherer vor änderungen. Oder bräuchtest du als pluginautor noch was?

mit macro mein ich auch eine folge solcher commands. halt ne folge an arbeitsschritten die man aufzeichenn und abspulen kann.

Ich habe den Thread jetzt nicht so genau verfolgt, aber es sieht so aus, als ob hier jemand wieder ein Templatesystem baut. Warum nicht einfach ein existierendes verwenden, z.B. das Schweizer Messer Template-Toolkit? Oder auch HTML::Template(::Compiled)?

Nein, ganz so mächtig sollte es ja nicht werden... Und wenn es - wie von mir vorgeschlagen - so etwas wie preprocess gibt, kann man die Templates mit HTC schreiben...

renee: mein vorschlag ist: man kann im template einen event benennen der fpr output gefeuert wird. du kannst beliebige routinen an events hängen. wär das was?

kann mir im Moment nicht so wirklich was darunter vorstellen. Das müsste man erst noch testen...

dein plugin macht die arbeit die es macht hat aber kein kontakt zu meiner codebase, was genau ist was ich erreichen will. deine routinen PPI untersunung+ insert text hinterlegst du als callback bei einem event der zum namensraum des moduls gehört. im template gibts du dann name des events aus den tu triggern willst.

Ich bin mal darauf gespannt...