Mehrere Businessobjekte in einem Layout

[Matthias Eckardt]

Guten Tag,

mal wieder was Kurzes:

http://wiki.nuclos.de/display/Konfiguration/Layout sagt, dass „[…] es können auch verschiedene angegeben werden.“. Das habe ich versucht, aber dann stehen nur die Felder des Businessobjektes zur Layoutgestaltung zur Verfügung, das ganz oben in der Verwendungs-Liste gelandet ist. Und obwohl ich einzelne Felder umsortieren kann (Zeile markieren, dann vorn beim > mit der Maus anpacken und hochziehen), wird beim nächsten Öffnen wieder das andere (meist unpraktischste) Businessobjekt promoviert.

Selbst Anlegen der Felder mit dem BO, das man dort hauptsächlich sehen will, Speichern, und anschließendes Hinzufügen der anderen BOs funktioniert nicht wirklich; die Felder bleiben zwar da (und es lässt sich speichern), aber die Vorschau und das reale Layout aus dem Menü beschweren sich mit dem Fehler, dass das Feld *komlizierte ID* aus dem BO *komplizierte ID* nicht zu sehen wäre.

Also keine multiplen BO in einem Layout?

[Ramin Goettlich]

Nein, das ist ein Missverständnis.

Ein Layout kann nur einem BO zugeordnet werden.
Ein BO kann aber mehrere Layouts haben (je Aktion, je Status, und später bald optional je Endgerät)

[Matthias Eckardt]

Servus,
und danke für die Antwort.

Aber das ist schon schade… Mehrere BO in einem Layout kombinieren zu können hätte gewiss viele nette Möglichkeiten eröffnet.
Ich weiß, wir können ein virtuelles BO verwenden, aber um dort reinschreiben zu können, fehlt uns noch immer die das Wissen über die korrekte Implementierung des Schreib-Proxy-Interfaces (genauer gesagt, das Wo)

[Ramin Goettlich]

Naja, eine Kombination ist natürlich in dem Sinne möglich, dass ein abhängiges BO im Layout des übergeordneten BO als Subform dargestellt werden kann.

Welche Arten von Kombinationen könnte man sich noch vorstellen?

[Matthias Eckardt]

Die direkten Abhängigkeiten per Subform-Referenz sollen nicht das Problem sein, aber sobald man mehr als einen „Hop“ zwischen Layout-BO und Ziel-BO hat muss man den Umweg über die ganzen Layouts gehen, die noch dazwischen liegen. (WENN die Relations-Tabellen-BOs überhaupt sowas haben)

Wenn eine Person und deren Adresse verschiedene BOs sind, und der Adresse PLZ von der Person 4 Hops entfernt ist, dann darf man bei der Neuanlage JEDES Layout auf dem Weg aufmachen und auf Neu klicken.

Wir haben gehofft, all die über mehrere Tabellen verteilten BOs in einem Einzelnen zusammenfassen zu können, um zu verhindern, dass man diese Umwege gehen muss. Im Beispiel sind das „nur“ 4 Hops, aber bei der stark normalisierten Datenbank, die wir versuchen zu verwenden, kann sowas auch schonmal über 8 und mehr Hops gehen. Da verliert man den Überblick, vor allem als potentieller Endkunde.

Ideal wäre eine View gewesen, in der man sich die Datensätze zusammensammelt, und über die man (per Regelmanager zur Not auch) auch Änderungen mit korrekten Relationen wieder in die Datenbank zurück überführen könnte.
Aber unsere Schwierigkeiten damit hab ich ja schon erwähnt.

[Ramin Goettlich]

Das verstehe ich nicht. PLZ muss doch (so würde ich annehmen) ein (ggf. Referenz)feld im BO Adresse sein.

Klar, wenn man einen neuen Datensatz erfassen will, und dabei gleich neue Datensätze in ganz anderen BOs mit erfassen will, muss man das in den jeweiligen Masken tun.

[Matthias Eckardt]

Vielleicht war Adresse nicht das am besten nachvollziehbare Beispiel. Nichts desto trotz, wir haben Bereiche, in denen die „zentrale“ Tabelle (das BO über das die meisten Relationen in andere Bereiche erfolgen) und deren am weitesten entfernte Untertabelle tatsächlich 4 Hops entfernt sind. Wenn man jetzt aus dem anderen Ende der Datenbank dafür neue Datensätze anlegen will, endet man mit einem Dutzend gestapelten Fenstern, um EIN Wort einzugeben.

Das klingt in der Theorie nicht so schlimm… aber man schafft es durchaus zu vergessen, für was man all diese Fenster eigentlich aufgemacht hat, oder wie die davor gelegenen Werte ausgesehen haben, wenn man im letzten BO in der Kette angekommen ist.

Deshalb hoffen wir, thematisch zusammenpassende BO in einem einzigen Layout zusammenfassen zu können. Mir ist klar, dass man mit einer insertregel eventuell nachhelfen muss, damit alle Relationen korrekt ankommen, aber das ist das geringste Übel.

[Claudia Mangstl]

Kurze Info zu den Proxy-BOs: die Proxy-BOs können nur als Unterformular eingebunden werden.

[Sebastian Günther]

Schreib-Proxy-BOs müssen hier von Proxy-BOs getrennt werden. Proxy-BOs können tatsächlich nur als Unterformulare eingebunden werden. Schreib-Proxy-BOs hingegen verhalten sich beim Lesen wie virtuelle BOs, können also auch als „Haupt-BO“ verwendet werden. Nur wird beim Schreiben (insert, update, delete) die entsprechende Methode des zu implementierenden Interfaces aufgerufen.

Das (generische) Schreib-Proxy-BO-Interface sieht folgendermaßen aus:


public interface .Proxy {
//Parameter "user" liefert aktuellen Benutzer
public void setUser(org.nuclos.api.User user);

//wird beim Speichern eines neuen Datensatzes aufgerufen
public Long insert(Boname pBoname) throws org.nuclos.api.exception.BusinessException;

//wird beim Speichern eines veränderten Datensatzes aufgerufen
public void update(Boname pBoname) throws org.nuclos.api.exception.BusinessException;

//wird beim Löschen eines Datensatzes aufgerufen
public void delete(java.lang.Long id) throws org.nuclos.api.exception.BusinessException;

//wird beim erfolgreichen Abschluss der aktuellen Transaktion augerufen
public void commit();

//wird beim nicht erfolgreichen Abschluss (Zurückrollen) der aktuellen Transaktion augerufen
public void rollback();
}


[Matthias Eckardt]

Und was ist mit den Schreib-Proxy-BOs? Jene, die ich einem Virtuellen Businessobjekt zuweisen kann, welches wiederum aus einem Datenbankobjekt des Typs „View“ hervorgegangen ist? Jener Punkt im BO Zauberer, der das ausgegraute, inaktive „BO kann editiert werden“ anhakt?
Die bekommen sogar eine eigene Maske (GUT!), aber um damit Dinge einzutragen, brauchen wir wieder die Schreib-Proxy-Implementiertung, über deren „Wo um Himmels Willen muss das hin?“ wir gerade im Umklaren sind.

EDit: Uh, jetzt ist eine Antwort dazwischen gekommen… bitte um Geduld, muss lesen 🙂

@guenthse, soweit, so gut. Den Inhalt des Interfaces haben wir über die IDE implementiert bekommen… aaaaber WO muss ich dieses Interface eigentlich implementieren?
Wir haben haben mit einer Inser-Regel versuchtn (ne), und der Kollege hat das sogar versuchsweise in die Java-Repräsentation eines BO gesteckt (auch ne).

Vermutlich ist eine eigene unabhängige Klasse erforderlich, die all das implementiert, aber wo muss diese dann eingetütet werden?

[Sebastian Günther]

Sie legen einfach eine „Serverregel“ (also wie Sie schon vermuteten einfach eine Klasse) an, die dann ähnlich lautet wie folgt:


public class BOProxyImpl implements .Proxy {
//Parameter "user" liefert aktuellen Benutzer
public void setUser(org.nuclos.api.User user) {
//do some stuff
};

//wird beim Speichern eines neuen Datensatzes aufgerufen
public Long insert(Boname pBoname) throws org.nuclos.api.exception.BusinessException {
//do some stuff
};

//wird beim Speichern eines veränderten Datensatzes aufgerufen
public void update(Boname pBoname) throws org.nuclos.api.exception.BusinessException {
//do some stuff
};

//wird beim Löschen eines Datensatzes aufgerufen
public void delete(java.lang.Long id) throws org.nuclos.api.exception.BusinessException {
//do some stuff
};

//wird beim erfolgreichen Abschluss der aktuellen Transaktion augerufen
public void commit() {
//do some stuff
};

//wird beim nicht erfolgreichen Abschluss (Zurückrollen) der aktuellen Transaktion augerufen
public void rollback() {
//do some stuff
};
}


Die Angabe des Fully Qualified Name des Interfaces ist hierbei essentiell, ansonsten findet Nuclos das Interface nicht, auch nicht wenn’s im gleichen Package liegt.

[Matthias Eckardt]

Guten Morgen,
und Danke für die Antwort.
Wir haben es jetzt endlich geschafft, aber es funktionierte erst, nachdem die Klasse $BOImpl genannt worden ist. Und Nuclos anschließend neugestartet worden ist.

Jetzt erwartet er nur noch, dass wir ihm beim insert die intid eines Datenbank-Datensatzes zurückgeben, und zwar aus der Tabelle die zu dem Virtuellen BO gehört. Was… ein Problem ist, oder? Immerhin ist das eine View, die keine wirkliche Tabellenrepräsentation in der Datenbank hat. Zumindest habe ich noch keine gesehen.

Das Ganze hat jetzt „eine letzte Frage“ Charakter bekommen, weil die Fehlermeldung zwischen uns und dem steht, was wir zu tun gedenken.

Darum: Wie teile ich dem Nuclos mit, dass es keine Datenbanktabelle für das Vrituelle BO gibt, aus der wir eine intid beziehen könnten?

[Autor]

Beiträge