Live Templates für PHP Storm

[rhorbas]

Ich steige im Moment mehr und mehr von Komodo Edit auf PHP Storm um, weil die IDE zusammen mit dem Editor Plugin einfach genial ist. Was mir noch fehlt, ist die über lange Zeit gepflegte Komodo Snippet Library mit den we-Tags.

PHP Storm bietet die Möglichkeit, über einen Tastatur-Shortcut eine Liste der Tags zu öffnen, die man dann durchsuchen und einfügen kann. Die möglichen Attributwerte werden dann als Auswahlliste angeboten, und man tabbt sich schnell durch ein we-Tag.

Die Snippets alle neu von Hand zu erstellen ist allerdings mühsam.
Storm speichert die Live Templates einer Gruppe in einer XML-Datei, die man sicher auch gleich automatisch generieren könnte.
Format:

Code: Alles auswählen

<templateSet group="webEdition">
  <template name="we:text" value="<we:textarea wysiwyg="$wysiwyg$" name="$contentname$&quot(...) />" toReformat="false" toShortenFQNames="true">
    <variable name="wysiwyg" expression="enum("true","false")" defaultValue="true" alwaysStopAt="true" />
(...)
          <context>
      <option name="HTML_TEXT" value="true" />
(...)
    </context>
  </template>
</templateSet>

2 Fragen habe ich hierzu:

* Gibt es eine we-Tags-Liste mit möglichen Attributen, die man als Vorlage verwenden könnte?
* Hat jemand Interesse, da mitzumachen, oder einfach am Endergebnis?

Der Tags-Assistent von WE ist zwar ganz OK, aber vom Workflow her ist PHP Storm einfach besser.

[AndreasWitt]

... ich hätte auf jedem Fall Interesse am Ergebnis. Ich nutze nämlich auch PHP Storm

[AndreasWitt]

... eventuell könnte man das Storm-Template auch aus der Tag-Referenz automatisch generieren.

[mokraemer]

ich nutze zwar netbeans, das wäre aber trotzdem interessant.
Nur müßte man ja eigentlich vorher mal an das Java-Plugin für den Editor ran. Denn die Schnittstelle stirbt ja in allen Browsern aus.
Aus WE heraus wird es somit unmöglich sein ein Pluign zu starten und dem die Daten aus dem Editor zu übergeben.
Was evtl. geht ist es, das im Browser ein websocket geöffnet wird und über den dann mit einer lokalen Anwendung kommuniziert wird. Wenn es hier ein Protokoll in php-storm / netbeans gäbe an das man sich andocken kann, wäre das extrem cool und man müßte auch nichts nachinstallieren.

Eigentlich ist das die wirklich wichtige Frage, denn die Datei aus dem Tagwizzard zu generieren wäre kein Problem - nur das Plugin macht mir echte Sorgen! Da bräuchten wir dringend Mithilfe.

[rhorbas]

Eigentlich ist das die wirklich wichtige Frage, denn die Datei aus dem Tagwizzard zu generieren wäre kein Problem - nur das Plugin macht mir echte Sorgen! Da bräuchten wir dringend Mithilfe.

Stimmt, das verdränge ich immer. Ohne das Plugin wäre ich echt aufgeschmissen, Java installiere ich nur noch deswegen, und mit Updates halte ich mich zurück, weil ich immer Angst habe, dass es danach nicht mehr läuft.

Ich habe kürzlich mal das AddOn "It's All Text" getestet, aber das ging nicht; vermutlich, weil das WE-Codefenster mehr ist als eine textarea, oder?
(...)
Den Text hier habe ich eben darüber mit Scite bearbeitet, das ging.
(...)
In einer WE-Installation, wo ich mit einer reinen Textarea arbeite, ging es auch: Zwar wird die Datei mit der Endung .txt geöffnet, sodass man von Hand die Sprache auswählen muss, aber es wäre erträglich. Also müsste es doch möglich sein, dieses AddOn zu forken und für WE anzupassen, oder?
https://github.com/docwhat/itsalltext

Zur Storm Library: Gibts denn die Tag-Referenz irgendwo als verarbeitbares Dokument? Cool wäre es, wenn man bei Änderungen der Tags die Live Templates immer neu generieren könnte. Das könnte sogar ein Online-Tool sein, wo man seine Präferenzen vorher angeben kann.

[rhorbas]

... ich hätte auf jedem Fall Interesse am Ergebnis. Ich nutze nämlich auch PHP Storm

Ist das nicht die coolste IDE ever?

Toll wäre es, wenn es für die wichtigsten IDEs solche Libraries gäbe. Es müsste doch möglich sein, einen Online-Generator zu schreiben, in den man evtl. noch ein paar Optionen eingeben kann, und der einem dann die passenden Dateien erstellt.

Im Fall von Komodo wäre das ein gezipptes Verzeichnis mit Dateien, die JSON-Code enthalten. Bei Storm ist es eine XML-Datei.

Wie ist denn die Tag-Referenz aufgebaut? Stammt die aus dem Objekt-Modul?

[AndreasWitt]

... ja, die Tag-Referenz basiert auf Objekten und Multi-Objekten.

[rhorbas]

... ja, die Tag-Referenz basiert auf Objekten und Multi-Objekten.

Wenn ich da einen Export haben könnte, kann ich was Entsprechendes bauen und dann zur Verfügung stellen!

[mokraemer]

Mist, mein Betrag von gestern hab ich wohl vergessen abzuschicken.

Nein, wir generieren das wenn aus dem Tagwizzard, nicht aus den Objekten. Sonst fehlen die Custom-Tags und der TW ist auch "aktueller".
Wir müßten dann aber auch schauen, wie man das aktuell hält. Klar kann man das manuell runterziehen und einbauen.

Das Tool muß trotzdem bald besprochen werden. Hab mir "It's All Text" auch mal angesehen. Das wird nicht taugen, denn
a) ist es nur für FF verfügbar
b) in Chrome verbieten es die Sicherheitseinstellungen Prozesse zu starten -> das wird in Firefox sicher auch nachgerüstet, dann setzen wir da auf ein sinkendes Schiff
c) Ghosttext etc. ist für FF, Chrome verfügbar, setzt aber im Prinzip nur auf genannte websockets. Dann brauchen wir das Plugin nicht und könnten das auch selbst anbieten. Vorraussetzung ist, man sollte sich das Protokoll da anschauen und den Server den man lokal betreiben muß damit das Dokument geöffnet werden kann. Den Server können wir ja übernehmen und die Schnittstelle dazu bauen. Es gibt hier aber nicht nur Ghosttext, sondern auch noch ein paar andere - sollte man mal schauen wie die sich unterscheiden und den besten Server auswählen (mehrere Dokumente - das können nicht alle).

[rhorbas]

Nein, wir generieren das wenn aus dem Tagwizzard, nicht aus den Objekten. Sonst fehlen die Custom-Tags und der TW ist auch "aktueller".

Wo findet man denn den TW in WE? Und wo hält der seine Daten vor?

[mokraemer]

ich finde es wichtiger das java plugin zu korrigieren, dadurch das du nun gewechselt bist, hat das andere für dich eine höhere prio, hilft aber aktuell nicht wenn auch der letzte Browser das Java-Plugin nicht mehr unterstützt und das dürfte nicht mehr lange dauern

Wir sollten also hier mal zusammen Gedanken machen, wie das aussehen könnte. Scheinbar ist es unumgänglich eine lokale Komponente zu haben die den Editor selbst aufruft.

Um deine Frage trotzdem zu beantworten, schau dir einfach
we_template::we_getCodeMirror2Tags an - da werden die Tags und Attribute für Codemirror extrahiert - für was externes sähe das sicherlich so ähnlich aus und sollte aus einem Refactoring der Funktion entstehen.

[WBTMagnum]

Kurzer Einwurf:
Anstelle eines Plugins zur Online-Bearbeitung, wäre es unserer Meinung nach sinnvoller Templates direkt über das Filesystem bearbeitbar zu machen. So kann man mit dem Editor direkt auf alle Templates zugreifen und spart sich das mit den Browser-Plugins komplett. Das mit den Rebuilds müsste man dann natürlich etwas anders lösen.

Just my 2 cents,
Sascha

[AndreasWitt]

... das mit dem Filesystem (z. B. über WebDAV o. ä.) wäre in der Tat komfortabler, macht aber andere Probleme vor allem, weil die Templates ja primär in der DB liegen und eben nicht im Filesystem.

[mokraemer]

naja das wäre wurscht, denn webdav ist ja ein virtuelles Dateisystem, dem kannst du auch die Inhalte aus der DB vorwerfen.
Hat aber eher das Problem, das Vorlagen nicht mehr gesperrt offen sind etc. Man bekommt zwar mit, wann eine Vorlage gelesen und gespeichert wird, aber eben nicht wann und wie lange sie im (externen) Editor offen ist. Und wenn an einem System auch mal mehrere Leute an Vorlagen arbeiten braucht es eben Locks.
Meine Erfahrung mit webDav war (bei größeren Dateien) auch eher wackelig, aber das trifft Vorlagen nicht ganz.

Außerdem nutze ich den Editor auch um CSS/JS und php-Klassen, also Dokumente zu bearbeiten - allein da ist Locking etc. wichtig.

[WBTMagnum]

Klar, wenn man primär online arbeitet, dann ist das mit dem Locking ist ein wichtiger Punkt. Das lässt sich mit dem Filesystem nicht mehr wirklich abbilden.

Zur Info:
Bei unserem Entwicklungsansatz wird primär mit den im VCS gespeicherten Quelltexten (Templates, HTML, CSS, JS) gearbeitet. Änderungen werden dann ins Back-End übertragen (dzt. Copy & Pest). Hier wäre es echt nobel, wenn direkt über das Filesystem gearbeitet werden könnte. Dann kann man Änderungen per Push am Zielsystem einspielen.

Wenn ich es mir aussuchen könnte, dann würde ich den Zugriff auf die Templates über das Filesystem dem Locking jedenfalls bevorzugen.


LG,
Sascha