Modellierung Zoo-Beispiel

[rowe42]

Bisher haben wir nur enzelne Aspekte des Zoo-Beispiels in Polymer implementiert. Ich fände es aber wichtig, das Zoo-Beispiel vollständig oder zu einem ausreichend großen Teil zu implementieren, damit man sieht, wie das Generierungsergebnis aussehen soll.

Die DDL und GUI-DDL finden sich im Gitlab hier: .../mdsd/barrakuda/wikis/demo

Vorschlag: Wir implementieren es wie beschrieben, aber lassen die "Enclosures" weg, also nur die "Animals" und "Keepers". Alles was zu "Enclosures" gehört (also auch die Views) nehmen wir weg. Das reduziert die Aufgabe, hat aber immer noch alle relevanten Bestandteile, z.B. Relationen, Komponenten auf einer Seite, verschiedenartige Feldtypen.

Voraussetzung ist, dass wir die Bestandteile (z.B. die Table) soweit sauber implementiert haben.

Bitte kurze Meinung dazu - ich würde dann die entsprechend abgespeckte DDL hier posten und auch gerne Teile der Umsetzung übernehmen.

@dragonfly28 @ejcsid @Baumfrosch

[xdoo]

Da ich bisher alles für die Enclosures implementiert habe, bin ich nicht dafür genau die weg zu nehmen :)

[rowe42]

OK, dann eben die Keepers weg?

Ich hatte nur die Enclosures vorgeschlagen, weil man dann die restlichen Entitites lassen kann, wie sie sind. Aber wenn man die Keepers wegnimmt, muss man auch nur die Zeile "keeper manyToMany zookeeper;" aus Animals entfernen.

[rowe42]

OK, hier der Vorschlag:

Zoo-DSL

domain animad package com.zoo version 0.1;

serviceModel administration package com.zoo.animad version 0.1 {

    // Lists (enumerations)
    // Contains static data that does not change
    customListType animals ["Elephant" "Giraffe" "Penguin" "Barrakuda"];
    customListType gender ["male" "female"];

    // Text Patterns
    // here we need a simple text type with a mininmal length of 2 and a maximum of 30
    customTextType textMin2Max30 minLength=2 maxLength=30;

    // Numbers
    // A simple floating point number
    customNumberType double pointNumber;

    // Dates
    // We need one date datatype for dates that lie in the past
    // and one for dates in combination with a time
    customTimeType pastDate inThePast date;
    customTimeType event dateAndTime;

    entity enclosure {
        enclosureID textMin2Max30 mainFeature searchable "A123";
        animals oneToMany animal;
    }

    entity animal {
        name textMin2Max30 mainFeature searchable "Paul";
        species animals mainFeature searchable "Elephant";
        birthday pastDate mainFeature "01.01.1990";
        gender gender "male";
        weight double "14.5";
        keeper manyToMany zookeeper;
    }

    businessAction createAppointment {
        purpose "Create an appointment at the veterinarian for an animal";
        given species animals;
        given animalName textMin2Max30;
        given reasonForAppointment textMin2Max30;
        then event;
    }
}

GUI:

 guiModel keeperinterface package com.zoo.animad version 0.1 {
    mainview animals;

    view animals appearsInMenu {
        component animals for administration.animal type Table {
            button detail navigatesTo animalDetailView;
        }
        component createAnimal for administration.animal type CreateForm {
            button save navigatesTo animals;
        }
        button CreateAppointment navigatesTo appointmentView;
    }

    view enclosures appearsInMenu {
        component enclosures for administration.enclosure type Table {
            button detail navigatesTo enclosureDetailView;
        }
        component createEnclosure for administration.enclosure type CreateForm {
            button save navigatesTo enclosures;
        }
    }

    view animalDetailView {
        component readUpdateAnimal for administration.animal type ReadWriteForm {
        }
    }

    view enclosureDetailView {
        component readUpdateEnclosure for administration.enclosure type ReadWriteForm {
        }
        relComponent enclosureAnimals for administration.enclosure.animals type TODONEUEKOMPONENTE {
        }
    }

    view appointmentView {
        button Send;
    }
}

@xdoo Für die neue Art Relationen aufzubauen brauchen wir wohl auch eine andere Komponente? Bisher gab es ja im Beispiel eine ReadEditComponent (zum Anzeigen der bestehenden Relationen) gefolgt von einer AddTable (zum Hinzufügen neuer Relation; wie man bestehende Relationen wieder entfernt, habe ich in der Demo nicht entdeckt). Aber beides passt ja nicht so ganz, oder? Ich habe oben mal als Platzhalter TODONEUEKOMPONENTE.

Sobald wir das festgelegt haben und alle zugestimmt haben, kann ich die beiden Codeschnipsel auch als Files im Repo ablegen.

[dragonfly28]

Ich finde, drei Entitäten dürfen es schon sein in der Bespielimplementierung. Man tut sich dann auch leichter, unabhängig voneinander an den themen zu arbeiten. Die aktuelle DSL befindet sich im Übrigen unter https://github.com/xdoo/lhm_animad_admin_service/blob/master/animad.barrakuda

[DirkGern]

Ich finde beides richtig. Komplette Beispielimplementierung und 3 Entitäten ;-) Über welchen Aufwand reden wir?

[xdoo]

Ich glaube auch, dass der Nutzen bei drei Entitäten größer als der Aufwand ist. An eine Arbeitsteilung glaube ich zwar in diesem Schritt nicht mehr, aber man sieht bei "copy & paste" sehr schön, b es sich gut generieren läßt. Auch Alex tut sich leichter die Muster nachzuvollziehen, wenn er mehr als zwei Entitäten hat.

[ejcsid]

Und außerdem - nur weil der Vorschlag kam, keepers rauszunehmen: Dafür hab ich die Liste als Beispiel implementiert.

[xdoo]

4 : 1 für 3 Entitäten

[xdoo]

Bleibt so wie es ist.