Erstellen von Verknüpfungen on-the-fly #56

rowe42 · 2018-01-12T14:27:40Z

Problem: In der aktuellen Implementierung kann man nur bereits existierende Elemente verknüpfen. Ein wichtiger Usecase wäre es aber, dass man Elemente on-the-fly erzeugen und dann gleich verlinken kann, ohne das aktuelle Element zu verlassen.

Beispiel Verknüpfungselement mit NEU-Button:

Optionen:

Beim Klick auf "Neu" wechselt die Oberfläche komplett zum zu erstellenden Objekt (hier: Fall), das teilausgefüllte Objekt bleibt aber temporär gespeichert und man kehrt nach Erstellung wieder zu diesem zurück (das neu erstellte Objekt ist dann automatisch verknüpft).
Beim Klick auf "Neu" öffnet sich ein modales Fenster, das den Inhalt des Formulars für das zu erstellende Objekt enthält. Nach Erstellung schließt sich dieses und man ist wieder im teilausgefüllten Objekt (das neu erstellte Objekt ist dann automatisch verknüpft).

Eine Herausforderung für beide Optionen ist Rekursivität, also wenn innerhalb des on-the-fly zu erstellenden Objekts ein weiteres Objekt on-the-fly erstellt werden soll (also bei Option 2 ein modales Fenster oberhalb des modalen Fensters).

So könnte das modale Fenster aussehen:

Fragen:

Wollen wir Objekterzeugung on-thy-fly über eine der o.g. Optionen realisieren?
Soll das als fester Bestandteil von Objektverknüpfungen schon mit generiert werden? Wenn ja, soll man in der DSL konfigurieren können, ob man on-the-fly-Objekterzeugung haben will?

xdoo · 2018-01-12T14:35:42Z

zu den Fragen:

Das ist m. M. nach eine Entscheidung des Projektes. Die muss nicht für die Referenzimplementierung gelöst werden.
Die DSL anzufassen ist der absolut letzte Schritt. Ich sehe auch nicht warum man das in diesem Fall tun sollte. Die Frage ob wir eine generierte Komponente für dieses Problem benötigen lässt sich relativ leicht beantworten. Stell ein issue ein, in dem du begründest warum das genriert werden sollte (der Grund kann nicht sein "mein aktuelles Projekt braucht das gerade ganz dringend") und wir stimmen ab.

xdoo · 2018-01-12T14:36:30Z

Ich nehme mal die Kollegen mit in die Diskussion: @dragonfly28 @ejcsid

rowe42 · 2018-01-12T16:35:28Z

Ich finde schon, dass die Referenzimplementierung dieses Feature bereits beinhalten könnte und sollte. Ich finde es im Arbeitsablauf sehr wichtig, dass es so eine Funktionalität gibt.

Und damit sollte man sich auch überlegen, wie sich der Generator bzgl. dieses Features verhalten soll - z.B. ein on-the-fly Generieren des zu verknüpfenden Objekts standardmäßig immer ermöglichen.

Dann wäre die DSL für so eine Komponente nach wie vor

relComponent enclosureAnimals for administration.enclosure.animals type ReadEditComponent

xdoo · 2018-01-12T17:05:57Z

Die Komponenten zu genrieren und in der DSL zur GUI Modellierung verwenden zu können sind aus meiner Sicht unterschiedliche Sachen. Wenn wir entscheiden so etwas ist wichtig, dann können wir sie generieren lassen. D.h. sie ist verfügbar und der Entwickler kann sie dann per Hand in die View einfügen. Der zweite Schritte wäre dann, sie in die GUI Modellierung mit auf zu nehmen.

DirkGern · 2018-01-15T08:46:22Z

Ich finde dieses Feature super und fände es sehr gut, wenn wir es mitgenerieren würden. Wenn das zu aufwändig ist, verschieben wir es auf Barrakuda 2.1 (gibt es eigentlich eine Roadmap?).
Besser als ein Button mit NEU fänd ich ein Symbol.
https://material.io/icons/#ic_add_circle
Zu Icons erstelle ich nochmal einen separaten Issue.

xdoo · 2018-01-15T08:54:41Z

Wie gesagt bei solchen Sachen ist immer die Frage:

Will ich es modellieren UND generieren können?
Will ich es NUR modellieren können

Fall 1 bedeutet immer einen Änderung an der DSL (die ich nicht überfrachten würde), Fall 2 kann man relativ einfach im Generator umsetzen, sofern man es einmal sauber implementiert hat.

dragonfly28 · 2018-01-15T10:31:38Z

KISS!!!
Relationen können ja bereits modelliert werden, je nach Datenmodell muss man dann die Objekte in der richtigen Reihenfolge anlegen. Mir wäre es wichtiger, eine einfache Default-Applikation zu haben die dann aber auch statt "Constraint validation!" ein korrektes Error-Handling bezüglich der Relationen anzeigt (z.B. den Hinweise "Sie müssen erst ein Gehege anlegen, bevor Sie ein Tier hinzufügen!").

xdoo · 2018-01-19T10:33:16Z

Mache ich im ersten Schritt für keepers.

xdoo · 2018-01-23T09:49:07Z

Modale Fenster funktionieren bei mir nicht. Siehe hierzu auch PolymerElements/paper-dialog#152. Ich werde das jetzt ohne modales Fenster implementieren. Aus meiner Sicht ist das kein Problem, weil ein Klick neben das Fenster dies einfach schließt. Nach dem Öffnen sind die Daten immer noch da. Insofern führt ein "Verklicken" nicht zu Datenverlust.

rowe42 · 2018-01-23T10:45:00Z

Es funktioniert, wenn man das Element in die index.html packt, wie du es auch schon mit dem toast machst. Siehe hier : https://github.com/rowe42/bezweck-showcase/blob/master/index.html Am 23.01.2018 10:49 vorm. schrieb "Claus Straube" <[email protected]

…

: Modale Fenster funktionieren bei mir nicht. Siehe hierzu auch PolymerElements/paper-dialog#152 <PolymerElements/paper-dialog#152>. Ich werde das jetzt ohne modales Fenster implementieren. Aus meiner Sicht ist das kein Problem, weil ein Klick neben das Fenster dies einfach schließt. Nach dem Öffnen sind die Daten immer noch da. Insofern führt ein "Verklicken" nicht zu Datenverlust. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYx7YdyDRcqCpcE2wUF9hVnZ8V_xcdPPks5tNasUgaJpZM4RcXQJ> .

xdoo · 2018-01-23T10:51:55Z

Ja, aber das passt nicht zum Anwendungsfall. Der Toast ist ein sehr generisches Ding, dem ich einfach einen Text schicke. Hier habe ich aber eine Komponente, die andere Komponenten in sich hat. Entweder habe ich n Dialoge (so viele wie wir Entiäten haben) in der index.html, oder ich manipuliere den DOM um da das Formular und die Buttons rein zu bekommen. Beides finde ich nicht gut. Dann lieber ohne modales Fenster.

rowe42 · 2018-01-23T11:02:46Z

Ich finde, dass es konzeptionell dem Toast sehr ähnlich ist. In beiden Fällen gibt es einen generischen Rahmen, der fallspezifisch mit Inhalt befüllt wird. Ein Unterschied ist sicher, dass man sich rekursiv mehrere modale Fenster übereinander vorstellen kann. Um das 100% zu lösen reicht auch nicht, so viele modale Fenster vorzuhalten wie es Entitäten gibt, da ja auch eine rekursive Anlage innerhalb einer Entität (z.B. "Tier hat Vater") vorstellbar ist. Ich würde deshalb vorschlagen, generell eine pragmatsiche Anzahl (5?) von modalen Fenstern vorzusehen, und wenn die genutzt sind, "ist halt Schluss" (mehr Stack kann sich der Nutzer im Hirn ja auch nicht vorhalten).
Ob ein Klick neben das Fenster das schließt oder nicht, lässt sich einstellen. Ich würde dazu tendieren, dies abzuschalten und stattdessen einen expliziten "Abbrechen" Knopf vorzusehen, wie man das von anderen modalen Fenstern auch kennt.

Was meinen denn die anderen? @Baumfrosch @Dr-Thomas-Tensi @ejcsid @dragonfly28

xdoo · 2018-01-23T11:46:42Z

Das ist aber technisch dem Toast nicht sehr ähnlich. Beim Toast mache ich folgendes:

index.html

<paper-toast 
        id="global_success_toast" 
        always-on-top>
</paper-toast>

Dann selektiere ich den in einer beliebigen Komponente und übergeben ihm die Nachricht als Property:

_success() {
            this._successToast.text = this.t('form_success');
            this._successToast.open();
        }

Das ist einfach. Ich habe ein Property und ich habe kein Datahandling. Ein Dialog schaut aber so aus:

<paper-dialog>
            <h2>Dialog Title</h2>
            <paper-dialog-scrollable>
            <!-- DAS IST INDIVIDUELL UND ABHÄNGIG VOM SCOPE -->
                <iron-form id="iform">
                    <form class="animad-keeper-create-dialog-form">
                        <animad-keeper-form data="{{_dialogdata}}" auto-validate></animad-keeper-form>
                    </form>
                </iron-form>
            </paper-dialog-scrollable>
            <div class="buttons">
               <!-- DAS IST ABHÄNGIG VOM SCOPE -->
                <paper-button dialog-dismiss on-tap="_resetForm">cancel</paper-button>
                <paper-button dialog-confirm on-tap="_saveDialog">save</paper-button>
            </div>
</paper-dialog>

Ich bette hier individuelle Struktur in den DOM ein (das hat nichts mit Stacking zu tun) UND ich brauche den Scope um die Datenverarbeiten zu können. Der Dialog hat definitiv nichts in der index.html verloren.

Dr-Thomas-Tensi · 2018-01-23T12:00:17Z

Generell finde ich das Konzept mit dem Anlegen an der Relation gut (das steht auch so im Navigationskonzeptpapier ;-). Wir haben eine Schwierigkeit: bei alleinstehenden Relationen gibt es kein Ausgangsobjekt, bei einer eingebetteten Relation schon. Das muss man entweder in der DSL unterscheiden oder der Generator erkennt den Kontext.
Die modalen Dialoge finde ich unpraktisch; das sieht man ja auch an Eurer Diskussion bezüglich der Schachtelungstiefe. Auch die Logik des Danebenklickens scheint mit trickreich:

überdecken sich die modalen Fenster vollständig?
wenn nicht, was passiert, wenn ich in ein darunterliegendes modales Fenster klicke: wird der Stack bis dorthin abgebaut?

Was spricht gegen eine vollständige Dialogumschaltung auf das neue Objekt? Nach der Anlage kann man wieder (mit einem History-Mechanismus z.B. per Knopf) zum ursprünglichen Objekt zurückkehren (die History der offenen Objekte könnte auch in der Navigationsleiste dargestellt werden, dann kann man hin und her klicken).
Mein Verständnis eines modalen Dialogs ist, dass er für eine Sondersituation steht, die man lokal und sofort behandeln muss. Das ist für mich bei einer Neuanlage eines Objekts nicht gegeben.
Offen bleibt, was für eine Speicherlogik verwendet werden soll: wenn bei einer Dialogumschaltung auf jeden Fall gespeichert werden muss, dann wäre die Stacklogik von modalen Fenstern vielleicht hilfreich.

#56

xdoo · 2018-01-23T12:11:36Z

@Dr-Thomas-Tensi du kannst gerne deine Meinung sagen, aber du schließt bitte nicht einfach irgend welche Issues. Das macht derjenige, der den Pull Request reviewed. Wenn beschlossen wird etwas nicht zu implementieren, dann macht es derjenige, der es eröffnet. Issues zu schließen um eine Diskussion abzuwürgen ist ein no go...

@ejcsid hat den gerade gemerged, insofern kann das Issue geschlossen bleiben.

xdoo · 2018-01-23T12:16:19Z

@rowe42 wenn du dich nicht dieser Meinung

Ich bette hier individuelle Struktur in den DOM ein (das hat nichts mit Stacking zu tun) UND ich brauche den Scope um die Datenverarbeiten zu können. Der Dialog hat definitiv nichts in der index.html verloren.

anschließen kannst, dann bitte dafür ein neues Issue aufmachen. Die geforderte Funktionalität ist erst einmal (ohne modales Fenster) implementiert. Ein modales Fenster ist wegen des oben beschriebenen Bugs eine größere Sache. Das sollten wir separat behandeln.

Dr-Thomas-Tensi · 2018-01-23T12:30:04Z

Hi Claus,
sorry, das Schließen war unbeabsichtigt, habe beim Hin- und Herschalten den falschen Knopf erwischt.
Gruß Thomas

DirkGern · 2018-01-23T13:04:11Z

Kann ich dem modalen Fenster eine Komponente übergeben?

xdoo · 2018-01-23T13:17:06Z

@Baumfrosch ja, das kann ich. Aber dann habe ich immer noch nicht den scope. Ein modales Fenster ist nichts anderes als das:

<!-- HIER WIRD MODAL REIN GESCHRIEBEN -->
<paper-dialog modal>
            <h2>Dialog Title</h2>
            <paper-dialog-scrollable>
            <!-- DAS IST INDIVIDUELL UND ABHÄNGIG VOM SCOPE -->
                <iron-form id="iform">
                    <form class="animad-keeper-create-dialog-form">
                        <animad-keeper-form data="{{_dialogdata}}" auto-validate></animad-keeper-form>
                    </form>
                </iron-form>
            </paper-dialog-scrollable>
            <div class="buttons">
               <!-- DAS IST ABHÄNGIG VOM SCOPE -->
                <paper-button dialog-dismiss on-tap="_resetForm">cancel</paper-button>
                <paper-button dialog-confirm on-tap="_saveDialog">save</paper-button>
            </div>
</paper-dialog>

xdoo · 2018-01-23T13:19:39Z

Ich schlage aber vor diese Diskussion bei Bedarf in einem neuen Issue fortzuführen. Dort sollte dann auch rein geschrieben werden, welche Anforderungen so ein Dialogfenster erfüllen muss und wie wichtig die sind.

Nur wegen eines Bugs und unklaren Anforderungen einen kruden Workaround (und das haben wir, wenn wir alle Dialoge in die index.html werfen) zu bauen halte ich nicht für sehr sinnvoll.

rowe42 · 2018-01-23T14:14:27Z

Ich finde es schade, dass hier keine echte Diskussion zugelassen wird, sondern der Code einfach gemerged und das Issue geschlossen wird.

Ein modales Fenster kann man erreichen, indem man in der index.html so etwas aufnimmt:

<paper-dialog  id="modal" alwaysOnTop with-backdrop style="width:800px" >
    <paper-dialog-scrollable  id="modalscroll"></paper-dialog-scrollable>
</paper-dialog>

und an der Stelle, an der man das Fenster befüllen will, so etwas:

<div id="xyz" style="display:none">            
    ...mein Content...
</div>

sowie JavaScript

_showModal() {
    var modal = document.querySelector('#modal');
    var modalscroll = document.querySelector('#modalscroll');
    modalscroll.innerHTML = this.$.xyz.innerHTML;
    modal.open();
}

Wo ist da jetzt das Problem?

xdoo · 2018-01-23T14:31:42Z

@rowe42 das sage ich dir gerne nochmal: Das Problem ist der SCOPE! Hatte ich glaube ich schon so sechs bis sieben mal erwähnt.

Ich finde es schade, dass hier keine echte Diskussion zugelassen wird, sondern der Code einfach gemerged und das Issue geschlossen wird.

Auch das sage ich dir gerne nochmal: Mach dafür ein neues Issue auf und begründe warum der Dialog modal sein muss. Da können wir auch gerne diskutieren. Und wenn es da überhaupt kein Problem gibt, dann kannst du es gerne auch implementieren und beweisen. Aber auch du brauchst einen Scope um mit den Daten zu arbeiten.

Für mich war das Hauptfeature, dass man eine Verknüpfung on the fly erstellen kann. In einem Dialogfenster. Das wurde implementiert. Und ja - sorry ich habe nicht erkannt, dass eigentlich die graue Fläche (die leider wegen eines Polymerbugs nicht richtig funktioniert) das Killerfeature ist. Aber du kannst da gerne ein neues Issue aufmachen. Hatte ich glaube ich schon zwei oder dreimal erwähnt.

Ich diskutiere in diesem Issue auf jeden Fall nicht mehr mit.

rowe42 · 2018-01-24T07:20:16Z

@xdoo Wo kann ich denn das Fenster in Aktion erleben? Es scheint so, dass _new in animad-relation-behaviour true sein müsste, und das wird, sobald in der HAL-Nachricht eine Relation "...New" enthalten ist. Aber in animad-animals-view wird http://demo7841195.mockable.io/animals/new referenziert, was es offenbar nicht gibt...

xdoo added frontend model labels Jan 17, 2018

xdoo added this to the RefArch_1.0 milestone Jan 19, 2018

xdoo self-assigned this Jan 19, 2018

Dr-Thomas-Tensi closed this as completed Jan 23, 2018

ejcsid added a commit that referenced this issue Jan 23, 2018

Merge pull request #118 from xdoo/_#56

05737a4

#56

xdoo removed the model label Jan 23, 2018

xdoo mentioned this issue Jan 24, 2018

'on the fly' Relation für Enclosure und Animal #122

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Erstellen von Verknüpfungen on-the-fly #56

Erstellen von Verknüpfungen on-the-fly #56

rowe42 commented Jan 12, 2018

xdoo commented Jan 12, 2018

xdoo commented Jan 12, 2018

rowe42 commented Jan 12, 2018

xdoo commented Jan 12, 2018

DirkGern commented Jan 15, 2018

xdoo commented Jan 15, 2018 •

edited

Loading

dragonfly28 commented Jan 15, 2018

xdoo commented Jan 19, 2018 •

edited

Loading

xdoo commented Jan 23, 2018

rowe42 commented Jan 23, 2018 via email

xdoo commented Jan 23, 2018

rowe42 commented Jan 23, 2018

xdoo commented Jan 23, 2018

Dr-Thomas-Tensi commented Jan 23, 2018

xdoo commented Jan 23, 2018

xdoo commented Jan 23, 2018

Dr-Thomas-Tensi commented Jan 23, 2018

DirkGern commented Jan 23, 2018

xdoo commented Jan 23, 2018

xdoo commented Jan 23, 2018 •

edited

Loading

rowe42 commented Jan 23, 2018

xdoo commented Jan 23, 2018 •

edited

Loading

rowe42 commented Jan 24, 2018

Erstellen von Verknüpfungen on-the-fly #56

Erstellen von Verknüpfungen on-the-fly #56

Comments

rowe42 commented Jan 12, 2018

xdoo commented Jan 12, 2018

xdoo commented Jan 12, 2018

rowe42 commented Jan 12, 2018

xdoo commented Jan 12, 2018

DirkGern commented Jan 15, 2018

xdoo commented Jan 15, 2018 • edited Loading

dragonfly28 commented Jan 15, 2018

xdoo commented Jan 19, 2018 • edited Loading

xdoo commented Jan 23, 2018

rowe42 commented Jan 23, 2018 via email

xdoo commented Jan 23, 2018

rowe42 commented Jan 23, 2018

xdoo commented Jan 23, 2018

Dr-Thomas-Tensi commented Jan 23, 2018

xdoo commented Jan 23, 2018

xdoo commented Jan 23, 2018

Dr-Thomas-Tensi commented Jan 23, 2018

DirkGern commented Jan 23, 2018

xdoo commented Jan 23, 2018

xdoo commented Jan 23, 2018 • edited Loading

rowe42 commented Jan 23, 2018

xdoo commented Jan 23, 2018 • edited Loading

rowe42 commented Jan 24, 2018

xdoo commented Jan 15, 2018 •

edited

Loading

xdoo commented Jan 19, 2018 •

edited

Loading

xdoo commented Jan 23, 2018 •

edited

Loading

xdoo commented Jan 23, 2018 •

edited

Loading