Standardübergang von Lesesicht auf Bearbeitungssicht für ein Objekt und Default-Lesesicht

[Dr-Thomas-Tensi]

Als Standardnavigation ist vorgesehen dass es bei Darstellung eines Objekts einen Übergang von Lese- zu Bearbeitungssicht gibt, der durch eine Aktion angestoßen wird.

Gibt es für diese Navigation eine Standardlogik (z.B. einen Edit-Button), die immer generiert wird?

Landen wir sonst bei der Navigation immer in der Lesesicht eines Objekts (das wäre jedenfalls so im Navigationskonzept definiert)?

[ejcsid]

@xdoo @dragonfly28 @rowe42 @Baumfrosch @ejcsid

[xdoo]

Navigation ist die Entscheidung des Projektes und nicht unsere. Unsere Aufgabe ist es, die Komponenten so zu gestalten, dass die Anwender (Programmierer, BRE, Fachdienststelle) möglichst hohe Freiheitsgrade haben.

Wenn du die Anwendung startest und anschaust, dann werden relativ viele deiner Fragen beantwortet werden.

[Dr-Thomas-Tensi]

Deine Argumentation ist schon nachvollziehbar, und ich erkenne auch gerne an, dass im Prototyp Navigationen passabel funktionieren.

Aber für mich ist das natürlich etwas schwierig: ein Auftrag an mich in der Arbeitsgruppe ist, generische Navigationsmechanismen zu überlegen, die wir entweder nur per Style Guide oder sogar per Generierung umsetzen. Das halte ich für sinnvoll, weil es dazu führt, dass Anwendungen aus unterschiedlichen Kontexten bezüglich Bedienung sehr konsistent sind; meiner Meinung nach ist das besser, als wenn jedes Vorhaben seine eigenen Ideen von Navigation implementiert.

Aber ich sehe, dass wir da nicht einer Meinung sind. Daher sollten wir das nochmals in der Gruppe diskutieren und dort entscheiden lassen.

[xdoo]

Aber ich sehe, dass wir da nicht einer Meinung sind. Daher sollten wir das nochmals in der Gruppe diskutieren und dort entscheiden lassen.

Ja, das sollten wir unbedingt tun :)

[rowe42]

Aus Gespräch mit @Baumfrosch: Wir stellen das im Generator so um, dass wir beim Aufruf des Editierens eines Objekts automatisch im Änderungsmodus sind (nicht im Readonly-Modus). Die ReadForm ist aber auch noch da und kann vom Entwickler stattdessen verwendet werden.

[rowe42]

Kommando zurück (@Baumfrosch @Dr-Thomas-Tensi):

Das lässt sich alles aus heutiger Sicht bereits in der DSL formulieren:

Fall 1: Edit in Tabelle führt zu Readonly-Formular, dort gibt es Button "Bearbeiten"

    view enclosures appearsInMenu {
        component enclosures for administration.enclosure type Table {
            button detail navigatesTo enclosureDetailView;
        }
    }
...
    view enclosureDetailView {
        component readEnclosure for administration.enclosure type **ReadWriteForm** {
           button cancel navigatesTo enclosures;
        }
    }

Fall 2: Edit in Tabelle führt zu Update-Formular, dort kann man also direkt "loslegen"

    view enclosures appearsInMenu {
        component enclosures for administration.enclosure type Table {
            button detail navigatesTo enclosureDetailView;
        }
    }
...
    view enclosureDetailView {
        component readEnclosure for administration.enclosure type **UpdateForm** {
           button cancel navigatesTo enclosures;
        }
    }

Fall 3: Edit in Tabelle führt zu Readonly-Formular, dort kann man aber nichts ändern

    view enclosures appearsInMenu {
        component enclosures for administration.enclosure type Table {
            button detail navigatesTo enclosureDetailView;
        }
    }
...
    view enclosureDetailView {
        component readEnclosure for administration.enclosure type **ReadForm** {
           button cancel navigatesTo enclosures;
        }
    }

Hinweis: Fall 3 ist in Polymer noch nicht implementiert (@eidottermihi braucht ihr das?).

Bzgl. Buttons: Es gilt die Konvention, dass der Button "save" immer speichert, die Buttons "cancel" und "detail" immer navigieren. Man muss diese Buttons aber explizit in der DSL angeben, sonst fehlt der Knopf im Generat und die Seite ist eine "Sackgasse".

@Dr-Thomas-Tensi Das sollte deine Anforderung bedienen. Können wir das Issue schließen?

[Dr-Thomas-Tensi]

@rowe42 Danke für Deine Erläuterung! Das heißt aber, dass die Navigation explizit in der DSL ausprogrammiert werden muss. Ich habe mit @olympialice gestern diskutiert, dass es zumindest eine Style-Guide-Vorgabe dazu geben sollte. Und eigentlich hätte ich gerne eine Standardgenerierung, die man sinnvollerweise konfigurierbar machen muss. Deine Anmerkung "wenn man da nix angibt, landet man in einer Sackgasse" deutet darauf hin, dass hier eine Lücke ist. @olympialice und ich machen einen Vorschlag, wie das generisch modelliert werden soll, den wir dann in der Gruppe diskutieren (und ggf. auch abmessern ;-) können. Daher würde ich das Issue zunächst gerne offen lassen.