Skripting / API

Dieses Thema im Forum "Vorschläge und Wünsche" wurde erstellt von Antares, 5. Februar 2008.

  1. Antares

    Antares Member

    Mir wurde von einigen Benutzern angetragen, das Papyrus eine script-Funktionalität fehlt. Ich kann dies nur bestätigen. Gerade die integrierte Funktion von Papyrus WORD und BASE lädt gerade zu einer derart flexiblen Nutzung ein.

    Welche Skriptsprache würdet ihr bevorzugen? Ich stelle schon einmal VBA, MS ScriptControl zur Diskussion, da Visual Basic von vielen Benutzern beherrscht wird. Auch PHP wäre eine nette Alternative.

    Gibt es einen gemeinsamen Nenner für Windows und Mac?
     
    Zuletzt von einem Moderator bearbeitet: 2. Mai 2017
  2. dotpap

    dotpap Active Member

    Hallo clemens.daehne.
    Ja, das vermisse ich auch.
    Es wäre sehr wünschenswert, wenn sich Papyrus dahin gehend öffnen würde.
    Wenn ROM das auch so sieht und dem folgt, sollte es aber zuvor eine Abstimmung unter registrierten Anwendern geben, welche Sprache den Zuschlag bekommt. Ich persönlich favorisiere PHP. Soll schnell erlernbar sein.
     
  3. No-Nonsense

    No-Nonsense New Member


    Ich hatte Ulli schon einmal Lua empfohlen (siehe <4cou239ltop8iq167dvfu3go71ggsm82mf@4ax.com>).

    Der Lua Compiler und Interpreter ist relativ klein (ca. 200KB), komplett in ANSI C geschrieben, portabel und damit für alle von Papyrus verwendeten Plattformen verfügbar und sehr schnell. Weiterhin ist Lua Open Source, kann dennoch in kommerziellen Produkten ohne Kosten verwendet werden und ist dementsprechend recht weit verbreitet: Lua Anwender.

    Für Papyurs sind meiner Meinung gerade die Stabilität, Geschwindigkeit und geringe Größe extrem wichtig.

    Mit der vom Entwickler von Lua entwickelten Bibliothek LuaSQL (ebenfalls Open Source und für kommerzielle Produkte frei verwendbar) besteht weiterhin auch die Möglichkeit der Anbindung an SQL Datenbanken wie PostgreSQL, ODBC, MySQL, SQLite, Oracle, and ADO.

    Gerade SQLite wäre meiner Meinung für Papyrus ebenfalls eine interessante Erweiterung. Es ist wie Lua komplett in ANSI C geschrieben, sehr klein, Open Source und dennoch für kommerzielle Produkte frei verwendbar und weit verbreitet: Most Widely Deployed Database und Well-Known Users of SQLite.

    -Jens
     
    Zuletzt von einem Moderator bearbeitet: 2. Mai 2017
  4. glucose

    glucose Well-Known Member


    Ein ähnlicher Vorschlag wurde vor ca. einem Jahr in <news://maus.computer.software.office.papyrus> unterbreitet, wobei die Sprache "Lua" genannt wurde (www.lua.org). Lua ist speziell zum Einbetten in andere Programme entwickelt worden, klein (ca. 200 kB), nur in ANSI-C verfasst (wie papyrus) und plattformübergreifend. Adobe Lightroom ist z.B. teilweise in Lua geschrieben.


    Ich fürchte, VBA und plattformübergreifend gehen nicht zusammen. Microsoft selbst hat im neuesten MS Office für Macintosh die Unterstützung für VBA entfernt.

    Mir persönlich würde ruby sehr gut in papyrus gefallen ;)
     
    Zuletzt von einem Moderator bearbeitet: 2. Mai 2017
  5. ike

    ike Member

    Moin!


    VBA verbietet sich schon von alleine, da es nicht plattformübergreifend ist. Leider ist deswegen auch Applescript nicht einsetzbar. Wobei die Frage ist, ob es unter Windows - ähnlich zu MacOS - die Möglichkeit gibt, dass externe Scriptsprachen eine Applikation steuern.

    Soll heißen: In MacOS ist - vereinfacht gesagt - eine scriptbare Applikation ein Objekt mit Methoden und Eigenschaften. Nun kann man ein Applescript starten, was das Applikationsobjekt steuert. Das Applescript läuft extern, im Interpreter des Betriebssystem, und steuert die Applikation, die keinerlei Interpreter zur Verfügung stellen muss, lediglich die Schnittstelle zu den Methoden und Eigenschaften.

    Ich finde diesen Ansatz sehr gelungen. Wenn es nun unter Windows ebenfalls eine solche Möglichkeit gibt, wäre das die plattformübergreifende Lösung. Z.B. könnte es für Windows für Papyrus ein OCX geben, mit dem sich Papyrus steuern ließe. Wenn nun unter Windows ein Interpreter beim OS mitgeliefert wird (war da nicht mal was?), müsste das OCX lediglich eingebunden werden, dann wäre Papyrus komplett steuerbar.

    Michael
     
    Zuletzt von einem Moderator bearbeitet: 2. Mai 2017
  6. glucose

    glucose Well-Known Member


    Ja, nennt sich meines Wissens Windows Scripting Host.

    Inwiefern ist das plattformübergreifend? AppleScript gibt es nicht für Windows und ich denke, es gibt eine ganze Reihe Anwender, die papyrus sowohl unter Windows als auch unter MacOS verwenden. Die wollen ihre Skripte ganz sicher nicht in zwei verschiedenen Sprachen schreiben.

    Die schon vorgeschlagene Sprache Lua würde dagegen papyrus auf allen unterstützten Plattformen mit einer einzigen Sprache steuerbar machen.
     
    Zuletzt von einem Moderator bearbeitet: 2. Mai 2017
  7. ike

    ike Member

    Moin!


    Es wäre eine Lösung, die mit wahrscheinlich relativ geringem Aufwand eine sehr OS-nahe Lösung darstellt.

    Das ist natürlich ein Argument.

    Vielleicht ließe sich beides machen. Damit Lua Papyrus sauber ansprechen kann, benötigt Papyrus ja Schnittstellen. Und ob die dann per Lua, Apple Script oder WSH angesprungen werden, sollte dann egal sein.

    Michael
     
    Zuletzt von einem Moderator bearbeitet: 2. Mai 2017
  8. No-Nonsense

    No-Nonsense New Member

    [quote title=ike schrieb am Sa, 09 Februar 2008 16:24]
    VBA verbietet sich schon von alleine, da es nicht plattformübergreifend ist. Leider ist deswegen auch Applescript nicht einsetzbar. Wobei die Frage ist, ob es unter Windows - ähnlich zu MacOS - die Möglichkeit gibt, dass externe Scriptsprachen eine Applikation steuern.
     
    Zuletzt von einem Moderator bearbeitet: 2. Mai 2017
  9. Ulli

    Ulli Administrator Mitarbeiter

    Skripting ist eher kein Thema, da das risikobehaftet ist, kompliziert und sehr viele Anwender abhängt. :eek:

    Geht mir viel zu sehr in Richtung Featureitis der Moloch-Programme. :rolleyes:

    Wird auch nur recht selten gewünscht, und wenn man konkret fragt

    "wofür denn?"

    kommen selten wirklich konkret sinnvolle Anwendungen.
     
    Zuletzt von einem Moderator bearbeitet: 2. Mai 2017