Listen als Parameter oder Rückgabewert von BusinessActions

[a52team]

Zusätzlich zu einzelnen Datentypen und Entities können auch Listen dieser Typen als Parameter bzw. Rückgabetypen in BusinessActions verwendet werden.

Für die Darstellung der Listen gibt es noch kein Muster.

[Dr-Thomas-Tensi]

Eigentlich würde ich erwarten, dass Listen bei BusinessActions genauso behandelt werden wie bei Entitäten (siehe auch Dein Issue #223). In dem Dialogstruktur-und-Navigationspapier wird folgendes vorgeschlagen:

• Mehrwertige Attribute (x..*) eines primitiven Typs werden serialisiert (z.B. leerzeichensepariert) und nach Bearbeitung wieder zerlegt.
• Mehrwertige Attribute (x..*) eines strukturierten Typs werden als lineare Liste von serialisierten Werten dargestellt oder es wird - wie bei einer Assoziation - eine Tabelle verwendet.

Das Zerlegen kann algorithmisch aufwändig werden, und man weiß auch nicht, ob der Anwender die Bestandteile durch Fehleingaben verhackstückt, aber das wäre ein allgemeiner Ansatz.

[xdoo]

Ich habe noch nicht verstanden was genau dir fehlt. Wir lesen schon über die API Listen. Hier zum Beispiel (gibt aber auch andere Stellen):

https://github.com/xdoo/lhm_animad_admin_html5/blob/1441001a8ed638c75494f279ca9cbb5eaab0d6b6/src/behaviors/animad-relation-behavior.html#L156-L185

[a52team]

Hallo, es ist in der Dsl möglich jeden Parameter bzw. auch den Rückgabewert als Liste dieser Datentypen zu definieren. Somit erwartet der Rest-Endpunkt der entsprechenden BusinessAction ein JSON-Objekt mit einem JSON-Array der jeweiligen als Liste definierten Datentypen.

Beispiel:

customTimeType TheDate date;
customNumberType TheInteger;
customTextType TheText maxLength=999 minLength=42;

valueObject TheVo {
    ...
}

entity TheEntity {
    ...
}

businessAction theBusinessAction{
      purpose "Parameters and return value as list";
      given theEntityList listOf TheEntitiy;
      given theDateList listOf TheDate;
      given theVoList listOf TheVo;
      given theIntegerList listOf TheInteger;
      then listOf TheVo;
}

[xdoo]

Ich schlage vor, dass wir sowohl für den Daten Ein- als auch Ausgang jeweils ein einfaches Formular generieren. Vergleichbar mit

https://github.com/xdoo/lhm_animad_admin_html5/blob/master/src/animad-keeper/animad-keeper-form.html

Die Formulare mit Logik (z.B. animad--create-form oder animad--update-form) würde ich an dieser Stelle nicht generieren, weil sich das Verhalten nicht standardisieren lässt. Der Nutzer bekommt also ein blankes Formular und muss die Logik, was er mit den Daten macht, selbst implementieren.

Was meint ihr dazu @dragonfly28 @rowe42 @ejcsid @FabianWilms

[FabianWilms]

Wenn du mit "Nutzer" den Entwickler meinst, stimme ich dir zu.

[xdoo]

Ja, mit Nutzer meine ich den Entwickler :)

[dragonfly28]

Wenn ich das richtig verstehe, soll aus dem generierten Formular hervorgehen wie die API der BusinessAction zu bedienen ist, oder? Soll das generierte Formular dann 1.) dynamisch den Aufbau solcher Requests ermöglichen, z.B. das 'Zusammenklicken' einer Liste von vorhandenen 'TheEntity' ermöglichen oder 2.) nur exemplarisch einen Request visualisieren?

[xdoo]

Wenn ich das richtig verstehe, soll aus dem generierten Formular hervorgehen wie die API der BusinessAction zu bedienen ist, oder?

Aus meiner Sicht sollte hier nur die Struktur des @RequestBody Objektes hervorgehen. Was mit den Daten passiert ist bei einer BA nicht vorhersehbar. Das muss der Entwickler selbst implementieren.

1.) dynamisch den Aufbau solcher Requests ermöglichen, z.B. das 'Zusammenklicken' einer Liste von vorhandenen 'TheEntity' ermöglichen

So wie wir es bereits bei Relationen auch gemacht haben. entweder findet man das Objekt, oder man erstellt es 'on the fly' . Ich denke aber, dass es viel häufiger vorkommt, dass wir hier einfache Parameter als Listen haben (siehe auch #224). Auf die würde ich mich im ersten Schritt konzentrieren. Deshalb gehören für mich die beiden Issues auch grundsätzlich zusammen.

Wie würde so ein Formular denn für das Beispiel aussehen?

Das darf derjenige zeigen, der dieses Issue übernimmt :) Ich würde aber im ersten Schritt kein fiktives Beispiel nehmen, sondern die Parameter für die BA, die wir bereits generiert haben. Da haben wir zwar keine Listen drin, aber dafür ein Enum:

package de.muenchen.animad.admin.administration.service.gen.businessActionParams;

import de.muenchen.animad.admin.administration.service.gen.domain.Animals_;

public class CreateAppointment_BusinessActionParameters {
    private Animals_ species;
    private String animalName;
    private String reasonForAppointment;

    public Animals_ getSpecies(){return species;}

    public void setSpecies(Animals_ species){this.species = species;}

    public String getAnimalName(){return animalName;}

    public void setAnimalName(String animalName){this.animalName = animalName;}

    public String getReasonForAppointment(){return reasonForAppointment;}

    public void setReasonForAppointment(String reasonForAppointment){this.reasonForAppointment = reasonForAppointment;}

}

https://github.com/xdoo/lhm_animad_admin_service/blob/master/animad-service-administration/animad-administration-service/src/main/java/de/muenchen/animad/admin/administration/service/gen/businessActionParams/CreateAppointment_BusinessActionParameters.java#L1-L22

[rowe42]

Wir besprechen mit BeZweck, ob wir das JETZT brauchen. Sonst wird es Meilenstein 4.