Das Notes Forum
Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: arieger am 12.01.11 - 23:19:58
-
Hallo,
gibt es eine Möglichkeit, in einer Notesansicht die Spaltenüberschriften variabel zu gestalten?
Ich könnte mir auch vorstellen, daß ich ein Konfigurationsdokument mit entsprechenden Werten vorgebe. Dann ist aber die Frage, wie hole ich den String mit beispielsweise @DbColumn in die Spaltenüberschrift. Soweit ich das gesehen habe, kann man da nur verbergen!!! Oder ???
Genial wäre es, wenn man den ersten Datensatz als Ansichtstitel verwenden könnte, aber wie? ???
Wer hatte schon mal so eine Anforderung/Problem? Hätte mir jemand einen Tipp?
Vielen Dank und viele Grüße
Anton
-
N'abend,
je nach dem was Du als variabel meinst.
Du kannst z.B. per Agent die View jeden Abend neu erzeugen lassen - schau dir dazu mal die Klasse Notesview. Da gibt es Elemente wie Title, etc. mit denen das geht. Nutze ich selbst in einer kleinen Datenbank.
CU,
Axel
-
...oder den View als einen Embedded View in einer Form öffnen. Im View geht m.E. kein @DBLookup bzw. @DBColumn.
Den View per Agenten ändern, dürfte bei großen und/oder weltweit-eingesetzten Lösungen vielleicht limitierend sein.
-
Hallo Wildvirus,
mit "variabel" meinte ich folgendes:
In einer Notesdatenbank importiere ich mehrere Excellisten in mehrere verschiedene Views (Maske 1 in View1, Maske2 in View2 usw. Nun ist mein Problem, daß die Bearbeiter den Titel der jeweiligen Spalte vermissen. Nun wäre es super, wenn man bspw. bei Liste1 die Spaltentitel per Formel beschriften könnte (Spalte 1-x). Genauso bei der View2, usw.
Vielen Dank
Gruß Anton
-
Ändern sich denn mit jedem Import die Feldbezeichnungen? Wenn es immer die gleiche Art Tabellen sind, die importiert werden, dann sollten doch auch die Überschriften immer die gleichen sein. Es muss ja auch eine Zuordnung von Excelspalte zu Feldname für den Import vorgenommen werden. Oder wird einfach in die Felder Spalte1 ... SpalteN importiert?
Ich denke nicht, dass der Wunsch so einfach umzusetzen ist, evtl. mittels DXL-Export der Ansicht, dann die DXL-Datei manipulieren und wieder importieren (habe das selbst noch nie gemacht). Dazu wird der Benutzer sicherlich mindestens Designer-Rechte haben müssen. Soll das von "gewöhnlichen" Usern ausgeführt werden?
Eine komische Anforderung (bzw. ich verstehe sie nicht wirklich)
-
Hallo Herr Klett,
wir wollen für ca. 300 User das OfficePacket abschaffen, daß ist unser Ziel. Wir haben im Jahr ca. 100 verschiedene Excellisten (!von IDA!), die von verschiedenen Bereichen und Personen abzuarbeiten sind, und genau das wollen wir in einer oder mehreren Lotus Notes Datenbanken abhandeln.
Soweit klappt das auch alles ganz gut bis auf die Spaltentiteln anpassen. Wenn ich keine Lösung finde, baue ich mir eben einen neuen Rahmen oberhalb der Ansicht und hinterlege da die Spaltentiteln.
Falls aber Ihnen oder jemand noch was dazu einfällt -> wäre es echt super.
Vielen Dank
-
Ich bleib mal beim Forumsüblichen Du ...
Das ist ja ein sehr interessantes Projekt, sehe es deutlich vor mir:
Eine universelle Schablone zur Darstellung von importierten Tabellen, die dann für jede Tabellenart zu einer eigenen Datenbank führt.
Dazu würde ich mir eine Mail-In-Datenbank bauen, in die IDA die Dateien sendet. In dieser Datenbank kann man zu jeder Tabelle die Zieldatenbank definieren. Ein periodischer Agent importiert die gesendeten Tabellen in die einzelnen Datenbanken und legt ein Profil- oder Einstellungsdokument in der Tabellendatenbank mit den Feldbeschreibungen ab.
Bei weiteren Importen könnte gegen dieses Einstellungsdokument geprüft werden, ob die Tabelle den richtigen Aufbau hat, ansonsten wird der Import mit einem Fehlerhinweis verweigert.
In der Mail-In-Datenbank noch die Importdefinitionsdokumente noch so gestalten, dass sie beim normalen Öffnen direkt die zugehörige Tabellendatenbank öffnen, so hat der Benutzer das Gefühl, alle Listen wären in dieser einen Datenbank (die kann man auch noch über ein Leserfeld nur den relevanten Mitarbeitern zur Verfügung stellen).
Mit dem automatischen Versand aus IDA und dem periodischen Import in die TabellenDBs läuft alles ohne manuellen Eingriff, das ist wirklich effektiv. Wenn Ihr das am Laufen habt, wollen das bestimmt andere Banken auch haben.
So kommen wir dann zum Problem der Spaltenüberschriften. Die würde ich einfach mit A, B, C ... beschriften und die entsprechenden Felder (FeldA, FeldB, FeldC ...) anzeigen. Im Frame wird die Felddefinition aus dem durch den Import angelegten Einstellungsdokument angezeigt (z.B. links, oder oben, wobei ich links vorziehen würde, weil da mehr Platz ist
A = Kundennummer
B = Kontonummer
usw.
). Auch in der Maske könntest Du die Feldbezeichnungen aus dem Einstellungsdokument errechnen (berechnet zur Anzeige).
Das ist zwar nicht 100%ig schick, aber nur ein winziger Makel in dem ansonsten wesentlich besseren Arbeiten, als mit irgendwelchen Tabellen, die irgendwo rumfliegen und von jedem geändert werden können. So könnte man Anmerkungen zu jedem Datensatz machen und auch noch protokollieren, wer die wann gemacht hat. Das bietet keine Tabelle in einem Officeprodukt.
Wie schon gesagt, ein tolles Projekt, wünsche viel Spaß und Erfolg dabei.
-
gibt es eine Möglichkeit, in einer Notesansicht die Spaltenüberschriften variabel zu gestalten?
Klares NEIN.
Da fragen wir schon seit ca. 7 Jahren bei IBM nach. Meiner Einschätzung nach wird das auch nie umgesetzt. Es gibt auch noch andere Stellen, wo man lediglich feste Werte eintragen kann.
XPages, kein Thema, da geht das, aber im "classic" client nicht.
-
Den Titel einer Spalte kann man ganz einfach man mit LotusScript ändern, und das seit Version 6.
To set: notesViewColumn.Title = title$
In der Designer Hilfe steht ein Beispiel dazu.
Andreas
-
Andreas: ja klar, das geht; aber eben nicht dynamisch / User.
-
Ich habs so verstanden, dass eine Datei per (Server-)agent importiert werden soll.
Vorschlag von Peter Klett:
"Ein periodischer Agent importiert die gesendeten Tabellen in die einzelnen Datenbanken und legt ein Profil- oder Einstellungsdokument in der Tabellendatenbank mit den Feldbeschreibungen ab."
In diesem Script könnten dann einfach aus der ersten importierten Zeile die Spaltenüberschriften generiert werden. Das wollte Anton doch haben, oder?
-
ok, wenn das so ist, dan habe ich das nicht richtig verstanden. Dann geht das natürlich so
-
Super, man lernt doch nie aus ...
Nachsatz: Und was passiert bei Updates durch den Designtask? Da muss man dann wohl jeden morgen periodisch die Titel neu rechnen lassen. Also doch nicht super, nur es geht
-
Die DB muss ja nicht unbedingt auf einem Design Template beruhen bzw. die Ansichten können vom Design abgeklemmt werden.
-
Wenn es nur um die eine Ansicht geht, kann man die doch über die designproperties vom update ausschließen.
-
Und dann wird die Spalte Z hinzugefügt, oder eine neue Aktion in der Ansicht zur Protokollierung oder oder.
Das Ganze beim Einsatz von 100 Datenbanken, die auf einer Schablone beruhen, ohne Designtask kaum denkbar
-
also ich würde im Template nur eine einzige Ansicht anlegen, die Quasi als "Vorlage" dient: Die hat eine Spalte, die die Formatierung aufweist, die man sich für alle Spalten wünscht.
Der Agent, der die Import- Konfigurationen ausliest, erstellt dann anhand dieser Vorlage pro Konfiguration eine Ansicht (Design ist geschützt), setzt die Selektionsformel, erstellt die Spalten und schreibt die Spaltenüberschriften.
Habe ich so schon gemacht, und der Agent kann dann entweder einmal Nachts laufen, oder aber bei Änderung eines Import- Konfigurations- Dokumentes.... Ob man das jetzt mit einer Ziel- Datenbank oder mit mehreren macht ist dabei relativ unerheblich.
DIe Einbindung in eine Gliederung macht man dann entweder über den Eintrag "Other Views" oder eben auch mit dem Agenten (auch Gliederungen lassen sich per LotusScript verändern)
Gruss
Tode
-
Hallo an Alle,
also, als ich mich gerade angemeldet habe, wollte nur kurz nachschauen, da vielen mir beinahe die Augen aus - ich bin total geplättet, mit soviel super Ideen, Antworten und Infos habe ich ich gerechten, um so mehr freut es mich jetzt:
@Peter
Genau so schwebt mir das vor, Mails aus IDA in die ImportDB, ein Agent benamst die Datei beim Ablegen auf ein Netzwerklaufwerk, den Import mache ich allerdings über den "SD-DataIntegrator" (Super Datenpumpe), danach muß das Vertriebsmanagement das Konfigurationsdokument ausfüllen (Listenname für die Gliederungen und Spaltentitel), angedacht Stand Heute sind 12 Monate mit a 10 Listen = 120 gleichzeitige zu verarbeitende Listen). Name der Datenbank "Flexible Listenbearbeitung", besteht aus ImportDB und HauptDb. Dann mache ich 12 Rahmengruppen, die ich von einer Hauptrahmengruppe individuell ansteuere. Die rechte Seite wir in 2 Zeilen geteilt, oben die Spaltentiteln, die ich mit Masken (Felder berechnet mit DBColumn) füttere, unten im rechten Rahmen ist die Listenansicht. Ein Dokumentablaufdatum überlege ich mir noch, ebenso Editor und Leserfelder zum ausfüllen.
Wenn die Datenbank langsam wird, weil zuviele Dokumente drin sind, kopiere ich sie, und teile sie in Halbjahre auf.
-
@Eknori:
ich glaube, daß wir bei Rudi schon mal über dieses Thema diskutiert haben, allerdings dachte ich, das nun seit R.8.5.1 die Spaltenbetitelung berechenbar sei, aber egal, ich gebe die Hoffnung noch nicht auf ???
@Glombi:
richtig: wenn es so geht, ich möchte die erste Zeile als Spaltenüberschrift hinbekommen, bei jeder importierten Liste, aber wie, genau das suche ich???
@Tode:
ich arbeite hierbei ohne Templates. Die Gestaltungselemente werden fest vorgegeben. Jede Liste in der ImportDB wird per Agent der Maskenname geändert und in die HauptDB verschoben.
Allen vielen herzlichen Dank - Ihr seit Super. Falls noch weitere Tipps vorhanden, einfach weiter.
Viele Grüße
Anton
;)
-
ich möchte die erste Zeile als Spaltenüberschrift hinbekommen, bei jeder importierten Liste, aber wie, genau das suche ich???
Wo ist denn hier genau Dein Problem, Anton? Wie das geht, steht doch in Post #8.
Sinnvollerweise sollte das vor dem Import erfolgen - ersatzweise danach, wenn Du aus den erzeugten Notes-Dokumenten dann noch ermitteln kannst, welches aus dem ersten importierten Datensatz stammt.
Bernhard
-
welches aus dem ersten importierten Datensatz stammt.
Die Informationen kann man sich beim Import doch gleich in einer Liste merken. Erster Dtensatz = ab in die Liste. Dann den Rest importieren
-
Deswegen schrieb ich ja "am besten vor dem Import": Also erste Zeile lesen (und merken oder gleich die ColumnTitles setzen), diese Zeile verwerfen und ab der zweiten Zeile den eigentlichen Import starten.
Damit dürfte dann aber die externe Datenpumpe überfordert sein. Den Import auch noch selber zu machen, kann ja aber nicht der Hit sein.
Bernhard
-
Nun bin ich wieder genau so weit, wie am Anfang, ich versteh' das Problem nicht.
Es sollen jetzt also nicht 100 verschiedene Tabellen, sondern nur 10 importiert werden, das ganze dann 12 mal im Jahr macht 120 (ist logisch). Alle Tabellen sollen in eine Datenbank gestopft werden, für jede Tabellenart gibt es eine eigene Maske, eine eigene Ansicht, eine eigene Gliederung usw.
Wenn jetzt eh schon für jede Tabellenart alles nochmal gebaut werden soll, wo ist dann das Problem, in jeder Ansicht je Tabellenart die Spaltentitel fest zu definieren?
Das ganze Konstrukt ist mir viel zu starr aufgebaut. Kommt eine neue Tabellenart dazu, muss das, was schon 10 mal existiert, ein elftes Mal gebaut werden. Verschwindet eine Tabelle, kann sie aber wegen der Aufbewahrungspflicht nicht einfach entfernt werden. Schön ist das alles vielleicht beim Inbetriebnehmen, mit zunehmender Dauer und natürlich kommenden organisatorischen Änderungen wird das Ding immer krautiger. Werden Änderungen in den Ansichten gewünscht (Schaltflächen, vielleicht eine weitere Ansicht nach Status u.a.), muss immer alles mehrfach umgesetzt werden. Da fallen mir bestimmt noch mehr negative Punkte ein, wenn ich länger drüber nachdenke.
Als fanatischer Verallgemeinerer würde ich eine Tabellendatenbank bauen, die EINE Tabellenart verarbeiten kann. Je Tabellenart wird dann eine Tabellendatenbank angelegt. In den Tabellendatenbanken können Verlinkungen über die zentrale Definitionsdatenbank zu den anderen Tabellendatenbanken (natürlich dynamisch, nicht hart gecodet) eingebaut werden. Für den Anwender macht es dann keinen Unterschied, ob er in der Gliederung eine andere Gliederung oder eine andere Datenbank aufruft.
Kommen dann noch Spezialanforderungen zu einzelnen Tabellen dazu (z.B. kleine Workflows zu einzelnen Datensätzen), können die auch wieder allgemeingültig gebaut werden, so dass sie in jeder Tabelle verwendet werden könnten, und falls nicht benötigt, werden sie dann per Konfiguration verborgen. Entscheidend ist, dass jede Funktion und jede Erweiterung nur einmal gebaut werden muss.
Nur in solch einer Struktur ist es m.E. sinnvoll, darüber nachzudenken, wie man Spaltentitel berechnen kann. Und um das Vererbungsproblem durch die Schablonen zu beseitigen, könnte man in die Definitionsdatenbank eine Aktion einbauen, die in allen Ansichten der Tabellendatenbanken den Gestaltungsschutz ein- und ausschalten kann. Beim Update dann ausschalten, Designtask laufen lassen, Schutz wieder einschalten und Titel neu rechnen lassen.
So wird dann aus dem einmalig einsetzbaren Projekt "Verwalte 10 Tabellenarten" das universell einsetzbare Produkt "Verwalte beliebige Tabellen".
Den Import würde ich auch selbst bauen, das ist wirklich kein Hexenwerk. Die Dateien aus IDA (IDA ist Cognos ReportNet, inzwischen zugehörig zu IBM (?)) mögen zwar die Endung "xls" haben, sind aber nur csv-Dateien. Wir importieren solche Listen täglich mit eigenen Routinen. Der Vorteil bei der eigenen Routine besteht einmal darin, dass, wie auch schon von Bernhard genannt, die erste Zeile als Spaltendefinition gelesen werden kann, und dass eine Listendefinition nur einmal hinterlegt werden muss. Sonst muss sie einmal für die ListenDB und einmal für die Pumpe hinterlegt werden. Zweimal die selben Daten erhöht sowohl Verwaltungsaufwand wie auch Fehlerhäufigkeit.