Feature Discussions

[deletedUser01]

Ich finde, die Formularsyntax ist sehr mächtig, aber auch sehr sehr umständlich zu entwickeln. Zwar ist das Copy-Paste aus der Hilfe sehr nützlich aber doch irgendwie nicht sehr intuitiv.

Wenn ich ein Formular erstelle, dann möchte ich doch gerne einfach meine Elemente erst einmal "runterschreiben", weiß aber schon, welchen Widget-Typ ich verwenden will, und wie der Platzhalter heißen soll. Die Sprache und das ganze "drumherum" kommen dann ja erst später hinzu. Aktuell muss ich aber immer gleich die Langinfos angeben, sonst validiert es beim Speichern nicht.

Vorschlag 1: Verwenden der allgemeinen XML-Syntax für Lokalisierung:

statt:
<LANGINFOS>
<LANGINFO lang="DE" label="..."/>
</LANGINFOS>

besser:
<label xml:lang="DE">Text</label>
<desc xml:lang="EN">Text</desc>

Dabei kann xml:lang auch entfallen und signalisiert die Fallbacksprache

Vorschlag 2: Verwenden einer ganz anderen "GUI"-Sprache:
Es gibt hier mehrere "GUI-DSL's" auf dem Markt, z.B. XUL, Snow, XAML oder auch GUIDSL der Fornax-Plattform oder auch einfach java.fx.
Cool wäre, wenn man nicht auf einer Syntax festgelegt ist, sondern (plugingetrieben) mehrere Sprachen - je nach Geschmack - verwenden könnte.

[witt]

Es gibt die Möglichkeit innerhalb des Formulars der sogenannten Kurzschreibweise die nach einem Speichern (STRG+S) das Formular entsprechend um die Langinfo Tags ergänzt. Hierzu müssen zum Tag immer nur die Attribute "name" und "label" angegeben werden und als Leere-Tag geschrieben werden.

Das ganze sieht dann so aus:

1) Angabe der notwendigen Elemente im Formular

<CMS_MODULE>

     <CMS_INPUT_TEXT name="pt_headline" label="Überschrift" />

</CMS_MODULE>

2) Jetzt STRG+S oder den Save Button in der Toolbar drücken

=> das ganze ergibt dann

<CMS_MODULE>

     <CMS_INPUT_TEXT name="pt_headline">
    <LANGINFOS>
      <LANGINFO lang="*" label="TEST3"/>
    </LANGINFOS>
  </CMS_INPUT_TEXT>

</CMS_MODULE>

Das würde ihrem Vorschlag 1 aus meiner Sicht schon abdecken.

Allerdings glaube ich, dass es langfristig eher dahin gehen sollte, dass man die Widgets gar nicht mehr schreiben, sondern ähnlich wie im Datenbankbereich ein entsprechender Wizard bereit stehen sollte. Siehe auch https://community.e-spirit.com/ideas/1038

[StefanSchulz]

besser:
<label xml:lang="DE">Text</label>
<desc xml:lang="EN">Text</desc>

Könnten Sie bitte etwas ausführlicher erläutern, warum diese Form "besser" ist?

Verwenden einer ganz anderen "GUI"-Sprache:

Was wäre denn der Vorteil bei frei wählbarer GUI-Sprache gegenüber der (einmalig zu lernenden) auf FS-Anforderungen abgestimmten Sprache?

Ansonsten stimme ich Daniel zu, dass eher ein grafisches Werkzeug zum Erstellen der Formulare eine langfristige Verbesserung darstellt.

[deletedUser01]

Stefan Schulz schrieb:

Könnten Sie bitte etwas ausführlicher erläutern, warum diese Form "besser" ist?

1. Die Syntax ist kurz (ähnlich kurz wie die Kurzform von Daniel Witt)

2. Die Syntax entspricht gängiger Praxis beim Erstellen von XML-Dokumenten und folgt dem Vorschlag der W3C, wie lokalisierte Versionen von Elementen anzulegen sind

3. Die Syntax wird von einschlägigen externen XML-Editoren "verstanden" und es wird Unterstützung beim Editieren von diesen dafür angeboten.

4. Es gibt Übersetzungstools, die bereits auf Basis dieser W3C-konformen Syntax automatisch XML-Dateien übersetzen können.

Was wäre denn der Vorteil bei frei wählbarer GUI-Sprache gegenüber der (einmalig zu lernenden) auf FS-Anforderungen abgestimmten Sprache?

FS ist nicht alleine auf dem Markt. Das Hauptkriterium, was wir immer wieder zu FS hören ist, dass die IDE "in den 80er Jahren hängen geblieben ist" und die Syntax zu umständlich und proprietär ist.

Klar, man legt sich irgendwann einmal (wenn ich jetzt mal die Kundenbrille aufsetze) auf ein bestimmtes CMS fest und steigt dort tief in die Benutzung dieses CMS ein (findet dann in Foren wie diesem teilweise noch Features, die man so erstmal noch gar nicht kennt) und ist glücklich.

Ich denke aber noch ein wenig weiter...

Eine frei wählbare GUI-Sprache hätte den Charme, dass

1. Sowas wie eine Logik (siehe zweiter Vorschlag) schon abgedeckt ist

2. Standardisierte vs. proprietäre Sprachen verwendet werden können

3. bereits einmal erlerntes Know-How in einer anderen GUI-Sprache weiterverwendet werden kann und nicht durch proprietäres Know-How ersetzt wird

4. Migrationen werden erleichtert

5. Es zielt mehr in Richtung plattformunabhängigere Entwicklung.

Wie gesagt, FS ist zwar Spitze, aber doch nicht alleine auf dem Markt. Gerade im Dienstleistungsbereich wollen wir Formulare (und auch Templates) bauen, die möglichst überall wiederverwendet werden können - egal in welchem CMS.

Der Kunde hat dadurch den Vorteil, dass wir Dienstleister ihn schnell auf sein gewünschtes CMS heben können, ihn bei der Migration von XYZ-CMS zu FS unterstützen können, er nicht alles wegschmeißen muss und er in seiner gewohnten Sprache weiterentwickeln kann.

Und... seien wir mal ehrlich: Ich finde, letztlich sehe ich in der Formularsyntax (bis auf eben spezielle Widgets, die sich in fast jeder UI-Sprache abbilden ließen) nix besonders FS-spezifisches. Und ich glaube, es wäre auch für Ihre Entwickler einfacher, weil eine UI-Sprache schon viel mitbringt. (nur als Beispiel: Das Rendering einmal auf Swing, einmal auf Web würde ja durch die UI-Sprache mitgebracht und muss nicht extra neu programmiert werden.)

...und es ist wieder ein weites Feld, mit dem e-Spirit Module (=Sprachplugins) vertreiben kann...

[StefanSchulz]

Ich vermute, hier liegt eine leichte Fehleinschätzung vor, was das Ziel der Formularsyntax in FirstSpirit ist. Im Gegensatz zu Frameworks wie XUL oder XForms wird hier nicht eine GUI in all ihren Einzelteilen definiert, sondern verschiedene Eingabekomponenten mit unterschiedlichem Komplexitätsgrad konfiguriert. Darunter sicherlich einfach umzusetzende Komponenten für Text- und Zahlwerteingabe, aber auch komplexere Listen-, Wysiwyg- und Referenzwertkomponenten. Das hier gleichzeitig einfache Layouting-Möglichkeiten zur Verfügung stehen ist sicherlich ein pragmatischer Ansatz.

Um die aktuellen Möglichkeiten auf ein allgemeins UI-Framework abzubilden, müssten wohl mindestens die folgenden Eigenschaften und Funktionalitäten durch ein Sprach-Plug-in abgedeckt werden:

• Bereitstellen eines Plug-in-fähigen Editors zur unterstützten Bearbeitung des Formularquellcodes
• Bereitstellen von Plug-in-fähigen Renderern (für Java und HTML) zur Darstellung eines Formulars, inklusive einer API
  • zur Kontrolle durch FirstSpirit (Setzen und Auslesen aktueller Werte, Fokussierung einzelner Eingabeelemente, Treffermarkierung aus einer Suche, Änderungsmarkierung verschiedener Revisionsstände, usw.) und
  • zur Bindung der durch das Plug-in dargestellten Eingabekomponenten an ihre den FirstSpirit-Kontext nutzende Implementierung
• Eine API zum strukturierten Zugriff auf alle/einzelne Felder inkl. Konfigurations-Eigenschaften des Formulars
• Eine Plug-in-fähige Abbildung zwischen Formular-Datentypen/-werten und FirstSpirit-Datentypen/-werten
• Eine Plug-in-fähige Abbildung zwischen Eingabekomponenten-Eigenschaften und der Formulardefinitions-Syntax

Entsprechend groß wäre der Aufwand auch seitens FirstSpirit, entsprechende APIs zur Verfügung zu stellen und den internen Arbeitsablauf umzustellen, um mit unsicheren Engines von Drittanbietern eine angemessene Usability zu erreichen. Die hierdurch erreichte Flexibilität rechnet sich jedoch nicht, da FirstSpirit nicht die Möglichkeiten hat, für jede beliebige Sprache Sprach-Plug-ins zu erstellen, und Drittanbieter auf Grund der Komplexität nur wenig Anreiz haben dürften, ein solches Plug-in umzusetzen.

Wir haben uns hier im Haus kurz die von Ihnen genannten Frameworks angeschaut, um die Möglichkeiten besser abschätzen zu können. Leider scheint keines der Frameworks entsprechende Eigenschaften zu bieten, um obige Anforderungen leicht umzusetzen. Auch ist die Renderingfähigkeit, insbesondere was entsprechende Komponenten in Java angeht, eher dürftig. Mir/uns würde natürlich sehr interessieren, an welches Framework Sie konkret gedacht haben, das eine ansprechende Java-GUI erzeugt.

Was mir gleich eingefallen ist, als ich Ihre Idee las, dass es sicherlich Sinn machen könnte, Konverter für die Umsetzung von GUI-Definitionen solcher Frameworks in das für FirstSpirit-Komponenten gedachte XML zu erstellen. Somit bliebe zwar die Erfordernis, dass der Vorlagenentwickler sich in FirstSpirit einarbeitet. Jedoch könnte jemand mit den entsprechenden Kenntnissen in FS unter Nutzung solcher Konverter auch Formulare aus GUI-Definitionen fremder Frameworks erstellen, von denen er oder sie keine Kenntnisse hat, und diese dann anwendungsoptimiert einsetzen. Die Erstellung solcher Konverter kann natürlich insbesondere auch durch Dienstleister selbst erfolgen, da keine inneren Entwicklungskenntnisse über FirstSpirit vonnöten sind. Da die Erstellung eines Konverters mit Kenntnissen beider Formularsprachen relativ einfach sein dürfte und die von dem Dienstleister selbst betreute Projekte mit eben diesem Umsetzungsaspekt erleichtert, sehe ich bei diesem Weg auch genügend Anreiz für den Ersteller.

[MichaelaReydt]

Hallo,

vielen Dank für die Idee zur Verbesserung von FirstSpirit. Es ist uns wichtig, aus den Erfahrungen unserer Kunden und Partner zu lernen. Aus diesem Grund schätzen wir Feedback und freuen uns über jede Anregung.

Wir haben das Thema noch einmal evaluiert, haben aber aktuell keine Pläne, es in absehbarer Zukunft zu bearbeiten. Daher können wir diesen Feature Request zum aktuellen Zeitpunkt nicht berücksichtigen.

Viele Grüße

Michaela