Die folgende Aufstellung führt Funktionen in Nuclos auf, die aufgegeben und nicht mehr weiterentwickelt werden, da bessere Alternativen in Nuclos existieren, mit denen die jeweils zugrundeliegenden Anforderungen abgebildet werden können. Zur Sicherung der Abwärtskompatibilität werden solche veralteten Funktionen für längere Zeiträume zwar weiterhin unterstützt, es wird aber empfohlen, die Nutzung solcher Funktionen in eigenen Nuclets zu vermeiden und ggf. nach und nach auf die neuen, besseren Alternativen zu portieren. Solange veraltete Funktionen bei der Entwicklung neuer Features in Nuclos keine Zusatzaufwände nach sich ziehen, bleibt die Unterstützung bestehen, es ist aber zunehmend mit Nachteilen im Zusammenspiel mit anderen Funktionen in Nuclos zu rechnen. Ist die vollständige Abschaffung einer veralteten Funktion unumgänglich, erfolgt auf dieser Seite eine frühzeitige Ankündigung mit mindestens sechs Monaten Vorlauf.
| Veraltete Funktion | Empfohlene Alternative | Grund für Aufgabe | Geplanter Zeitpunkt für vollständige Abschaffung |
|---|---|---|---|
| Alte Regeln | Nuclos API, neue Regeln | Für alte Regel ist aufgrund dafür fehlender API keine Abwärtskompatibilität sicherstellbar. | Nuclos 4.0, Detailinformationen siehe Alte Regeln in Nuclos 4.0 |
| Dynamische Entitäten | Virtuelle Entitäten | Virtuelle Entitäten erschlagen alle Anforderungen an dynamische Entitäten, bieten aber mehr. | - |
| - | |||
| String für Zeitangaben in Ressourcenplanung | Datentyp Datetime | Datetime wird als zukünftiger nativer Datentyp in Nuclos Uhrzeiten unterstützen und den heutigen Workaround der Abbildung von Zeiten als Text überflüssig machen. | - |
| Wertelisten | Entitäten | Aus Wertelisten werden sowieso schon Entitäten generiert. Die noch vorhandene hauchdünne Unterscheidung zwischen einer Werteliste und einer Entität erhöht die Komplexität, hat aber keinen Vorteil. | |
| Übergeordnete Benutzergruppe in Benutzergruppenadministration | Hat keine Funktion | ||
| Berechtigungen auf Konfigurationswerkzeuge | Zukünftig sollen nur noch Superuser die Werkzeuge (Entitätenwizard, Layouteditor, etc.) im Menü "Konfiguration" nutzen sollen, keine Berechtigungsstrukturen auf Werkzeugebene mehr. Berechtigungnen für die Einträge des Menü "Administration" bleiben bestehen. Zu klären ist noch die Zuordnung der Einträge (z.B. Benutzergruppen nach Konfiguration? Webservice nach Konfiguration?) | ||
| Aufgabenlisten | Die Aufgabenlistenfunktionalitäten sollen aus Nuclos herausgenommen werden, da sie eher fachlicher Natur sind und damit eher in einem Nuclet anzusiedeln sind als im Nucloskern. | Nuclos 4.18, NUCLOS-6098 - Abrufen der Vorgangsdetails... STATUS | |
| Gruppen (ehem. Objektgruppen) | Mandanten, Datensatzfreigaben | Die Funktionalität der Objektgruppen ist Altlast, wird in Projekten nicht verwendet und wurde bereits durch andere Möglichkeiten abgelöst. Sollte daher aus Nuclos entfernt werden. Stellen in der GUI: Menüpunkte Konfiguration/Gruppe und Gruppierungsart und in der Maske Benutzergruppen, Unterformular Modulrechte die Spalte Gruppe | |
| Beziehungsart | Baumkonfiguration über den BO-Wizard | Funktion wird nicht mehr verwendet. Bitte entfernen |
Ausgegraute Zeilen der vorhergehenden Tabelle kennzeichnen Funktionen, die bereits abgeschafft wurden.
Überblick
Inhalte
9 Kommentare
Frank Pavlic sagt:
Nachschlagefelder sind keine architektonische Fehlentscheidung, eher ein ungemein gutes Feature und Nutzen gibt es sehr wohl hierfür.
Zum Beispiel ist es besser und vor allem richtig, nicht nur auf einen Preis in einer Preistabelle zu referenzieren, sondern
den Preis als solchen in Bestellungen, Aufträgen, usw. eingetragen zu haben, inkl. der schicken Möglichkeit, nach Preisen nachschlagen zu können.
Gibt es eine Alternative dazu? Preis referenzieren und per Regel dann den Wert in Auftragsposition übertragen? Nicht wirklich und auch umständlich.
Auch wird es umständlicher, den Preis in den folgenden Jahren zu ändern. Preis-Datensatz löschen geht nicht, einfach anpassen auch nicht, da sonst
alle Aufträge dann verfälscht werden. Nur Referenzfelder als Alternative sind für diesen Fall keine Option!
Nachschlagefelder bieten genau dann einen Mehrwert, wenn Daten nicht per Referenz sondern der Wert in den neuen Datensatz übernommen werden sollen
mit der Funktionalität eines Referenzfeldes. Geradliniger geht es nicht.
Wieso nicht eine Alternative anbieten: dem Referenzfeld eine Boolean-Eigenschaft verpassen, "Wert übertragen". Dann kann der Admin selbst entscheiden,
ob dieses Referenzfeld die ID oder aber den tatsächlichen Wert des Anzeigefeldes in den neuen Datensatz übernehmen soll!
Max Kalhammer sagt:
Ich denke auch, daß es für (meine jetzige Implementation) wichtig ist, einmal erstellte Daten (z.B. Angebote, Aufträge) belassen zu können, selbst wenn sich Stammdaten (z.B. Artikel) später ändern. Ich sehe im Grunde momentan auch keine Alternative.
Ramin Göttlich sagt:
Schön dass die Seite Ihren Zweck erfüllt! Wir haben das Feature gebaut, da wir die Funktion in einem Projekt benötigt haben. Dann aber doch nicht (wurde doch ein Referenzfeld), daher der Schluss: Fehlentscheidung. Dass das Feature so gern und intensiv genutzt wird, war uns nicht klar, schön das auf diesem Wege herauszufinden.
Warum man Artikel in Aufträgen referenzieren sollte, und diese Artikel dann löschen will, ist mir nicht wirklich klar, und das mit den nachzuschlagenden Preisen würde ich mit der "Wert nachschlagen" Layoutregel lösen. Warum ist das denn kein möglicher Lösungsweg?
Wir werden das Feature also beibehalten.
Frank Pavlic sagt:
In unserem Fall wird Nicht der Artikel gelöscht, sondern ein Artikelpreis wird verändert/gelöscht.
Zu einem Artikel kann es mehrere Preise geben, z. B. Staffelpreise, Kunden bzw. Lieferantenabhängig, usw., also Entität "Artikel" und Entität "Artikelpreise" .
Und da kommt es schon öfters vor, dass Preise im Laufe eines Geschäftsjahres sich öfters ändern können bzw. gelöscht werden, um Preisleichen zu vermeiden.
die Idee "Layout-Regel" ist in unserem Fall nicht gut, das es mehrere Preise zu einem Artikel gibt (>1000 Preise pro Artikel),
LOV und Nachschlagefeld ist aber genau die Lösung, Preisliste wird abhängig von Menge und Lieferant/Kunde weiter eingeschränkt. Preis kann aus der Liste ausgewählt werden, trotzdem bleibt aber noch die Möglichkeit, einen "freien" Preis eingeben zu können. Das geht mit Referenzfeldern nicht.
An dieser Stelle vielen Dank für den Erhalt des Features.
Matthias Haake sagt:
Ich habe eine Frage zur Aussage "Virtuelle Entitäten erschlagen alle Anforderungen an dynamische Entitäten, bieten aber mehr.".
Nachdem ich grade meine erste virtuelle Entität angelegt habe, muss ich feststellen, dass folgende Anforderung (noch) nicht erschlagen wird:
Bei einer Entität (z.B. Kunde, Mitarbeiter etc) gibt es ein Subform "Kontaktinformationen". Hier wird die virtuelle Entität eingebunden (schreibgeschützt). Die VIEW dieser virtuellen Entität sammelt per UNION-Befehl Daten aus verschiedenen Entitäten (Telefonnummern, E-Mailadressen usw.). In einer dynamischen Entität kann man per Doppelklick oder Kontextmenü den eigentlichen Datensatz öffnen. Das geht mit virtuellen Entitäten nicht. Oder übersehe ich da eine Möglichkeit?
Daher machen die dynamischen Entitäten durchaus Sinn, da sie Datensätze aus verschiedenen Entitäten zusammenführen können und die Verlinkung auf die richtige Maske vornehmen.
Maik Stüker sagt:
Nachschlagefelder lassen sich einfach per Layout erstellen, in dem man eine ComboBox verwendet und "erlaube beliebigen Ausdruck" wählt. Jetzt gibt man den Namen des Textfeldes ein und setzt noch einen passenden VLP. Schon hat man eine Nachschlagefunktion. Das ist noch etwas umständlich, zugebenen, und auch ausbaufähig. Aber ich bin über dieses Weg "gestolpert", weil sich ein Nachschlagefeld in einer Virtuellen Entität nicht einrichten lies. Und ein VLP ist um einiges flexibler als eine feste Referenz!
Frank Pavlic sagt:
Ist es aber nicht so, dass auch eine Combobox die intid des referenzierten Datensatzes in der Datenbank im Feld hinterlegt und nicht den Wert ? Denn genau das soll ja nicht passieren. Dann finde ich die ComboBox-Eigenschaft "erlaube beliebigen Ausdruck" im Layout-Editor der 3.11 nicht. Es gibt allerdings "Werteliste editierbar", ist es diese Eigenschaft ?
VLP kann ich auch bei einem Nachschlagefeld hinterlegen. Von daher ist der Luxus bereits da
. Ich weiss nicht, wie es ab nuclos 3.11 ist, aber Comboboxen litten doch unter Performance-Problemen, wenn viele Daten das Resultat des VLP waren,da die erst vollständig an den Client übertragen wurden, bevor man das Feld verwenden konnte. Das kleine Detail war der Unterschied zu einem LOV-Feld.
Ist dem immer noch so?
Dennis Mettel sagt:
Meiner Meinung nach müssten "Benutzer" und "Benutzergruppen" auf jeden Fall nach "Konfiguration" verschoben werden. Sonst kann sich ja zum Beispiel jeder Anwender selbst einen Benutzer definieren und mit Berechtigungen bestücken, die er sonst nicht hat.
Ramin Göttlich sagt:
Das sollte besser ins Ticketsystem. Die Benutzeradministration ist in unseren Augen eher eine administrative Funktion, und scheint uns dort wo sie jetzt ist, am besten angesiedelt. Natürlich kann man die Rechte auf die Administration von Benutzern und Benutzergruppen steuern!