Aktionsleiste per Lotusscript manipulieren

[jo@chim]

Ist es möglich die Aktionsleiste in Forms per Lotusscript manipulieren? Habe nichts dazu gefunden.
(Per DXL-Stream sollte es doch allemal möglich sein?)

[pram]

Per DXL ist es möglich, ja.

Allerdings ist DXL nicht 100% round trip fähig:
- Bilder verlieren manchmal die Skalierungsinfos.
- Hotspots verlieren manchmal die Funktion (ein Speichern im Designer hilft)

Du kannst die Maske relativ einfach auch im Designer als DXL öffnen und speichern. Dann schauen was kaputt geht.

Es ist vielleicht keine schlechte Idee, den Maskeninhalt in eine teilmaske auszulagern.

VG
Roland   

[jo@chim]

Per DXL ist es möglich, ja.

Hatte schon befürchtet, dass es nur per DXL geht... riecht so nach Weihwasser. Und das mag ich nicht 

Gibts irgendwo ne schöne Ressource, die sich mit dem Handling von Design-Elementen per DXL befasst?

[jo@chim]

Nachtrag: es geht bei dem Ganzen darum, eine (sukzessive alle) unserer DB's per Zugriff auf eine Language Library mulitlingual zu machen (7 Corporate Languages inkl. Chinesisch).

Wenn ich in Elementen, die ich formelbasiert anzeigen kann/muss, entsprechende DBLookups auf die Sprachdatensätze setze, sollte das doch irgendwann von der Performance her ein Problem geben, oder?

Spricht etwas dagegen, die Übersetzungen in ein Richtextfeld in einem Profildokument zu importieren? Müsste dann doch wesentlich schneller sein im Zugriff?

[cg-home]

Hi Achim,

letztes Jahr habe ich auch mit Mehrsprachigen DBs angefangen.

So wie ich es bei Dir verstehe, willst du die Sprachkonfiguration in eine
Zentrale DB machen. Ist auch eine Möglichkeit vor allem da man ja
bestimmte Begriffe immer wieder benötigt. Wie es hier mit der Performance
aussieht kann ich mangels Erfahrung nicht sagen.
Das hatte ich auch zuerst überlegt, aber da ich das nicht abschätzen konnte
bzgl. Replikation, Internetverbindungen usw. habe ich mich dagegen entschieden
und es in jede DB eingebaut.

Ich habe in jeder DB eine eigene Sprachkonfiguration und zwar nicht über
DB-Profile sondern ganz normale Dokumente.
Für jede Maske habe ich eine Sprachkonfiguration für die Felder und auch
noch eines für die Meldungen (Pflichtfelder usw.).
Für die Aktionen und die Navigation habe ich dann zusätzlich eine Sprachkonfiguration.
Das ganze funktioniert bisher ganz gut und ohne merkliche Performance Probleme.
Das geht alles überwiegend über Formelsprache, auch die Aktionen.
Werte die nicht berechnet werden können (oder nicht so einfach) mache ich
einfach fest in english (Spaltennamen, Titel von Tabellentabs).
Auswahl und Optionsfelder sind in der Maske auch über Aliase in der gewünschten
Sprache sichtbar (Bei uns derzeit nur Deutsch und English). In Ansichten sind die Inhalte
dann nur englisch oder bei Kategorien auch zweisprachig.
Dazu muss ich das in der Maske aber extra berechnen und könnte somit nicht aktuell sein.
Ist vermutlich auch nicht ganz Optimal aber bisher klappt es erstaunlich gut. ;-)

Bei 7 Sprachen ist das ganze natürlich schon um eininges komplexer vor allem
wenn Chinesisch dabei ist. Das würde ich auch nicht wirklich anfangen wollen.
Bei uns kommt ggf. noch französisch dazu. Unsere Firma bietet unseren Mitarbeiter bei
den Töchtern Sprachlehrgänge an deutsch oder englisch.

Eine andere Variante hatte ich mir auch noch überlegt (auch nicht von mir erfunden) und
zwar eine zentrale Sprach-DB machen und diese Inahlte dann in die einzelnen DBs
entsprechehend übertragen ggf. auch in ProfilDoks. Somit hätte man den Vorteil der
zentralen SprachKonfig-DB und den performanteren internen Zugriff in den einzelnen DBs.
Aber das ist schon um ein einiges komplexer Aufzubauen und hatte es wieder verworfen.

Geklaut und etwas für mich angepasst habe ich es mir vom HELP!! System von openntf.

Gruß Christian

[jo@chim]

Eine andere Variante hatte ich mir auch noch überlegt (auch nicht von mir erfunden) und
zwar eine zentrale Sprach-DB machen und diese Inahlte dann in die einzelnen DBs
entsprechehend übertragen ggf. auch in ProfilDoks.

Ja, genau so habe ich es mir überlegt nach einigem Ausprobieren und Recherchieren am Wochenende. Mit dblookups würde ich in die Geschwindigkeitsfalle geraten. Nicht dass mir hier noch einer den Titel "Performancekiller des Jahres" verleiht ;-)

Die Language Library steht ja schon. Per "Translations Update"-Agent werde ich die Sprachtabelle in ein Profile Doc übertragen bzw. aktualisieren bei Bedarf. In den DB's kann dann per @formulas und LS-Funktionen (aus einer lnglib-Bibliothek, die für alle DB's identisch ist und als lss importiert wird) zugegriffen werden.

Das mit den Views ist nicht das Problem: die Spalteninhalte und Titel können ja gut per LS manipuliert werden. Gibt es halt für jede Sprache nen eigenen. Es geht ja nur um die Benutzeransichten.

Mir ist wichtig, dass das System für alle DB's, auch diejenigen, die ich nicht entwickelt habe, leicht anwendbar ist.

[Thomas Schulte]

Was ich spannend finde ist das was du zur Manipulation von Spaltentiteln und Inhalten per LS gesagt hast. Das würde mich interessieren wie du das machen willst.
Ich habe mich lange nicht mehr mit !!HELP!! beschäftigt. Aber wenn es da etwas gibt was funktioniert, dann würde ich das tatsächlich dort einbauen.
Wir haben damels verschiedene Lösungsmöglichkeiten ausprobiert. Aber alle verworfen, weil sie eben nicht zur Laufzeit funktioniert haben ohne das zum Beispiel jedesmal der View Index neu aufgebaut werden musste.

[jo@chim]

Das kannst Du per View NotesViewColumn.Title bzw. NotesViewColumn.Formula machen, ich glaube seit Version 6

http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_designer.nsf/f4b82fbb75e942a6852566ac0037f284/60baaa18e9f14b038525704a00412cef?OpenDocument

[eknori]

Das ist dann aber global und nicht per user.

@Thomas: Seit wir uns daran versucht haben, ist im Client nichts Gravierendes passiert. Weiterentwicklung des Notes Client findet offensichtlich nicht mehr statt.

[jo@chim]

Wenns "nur" um die SelectionFormula geht, arbeite ich mit @SetViewInfo, das funktioniert sehr gut hier. Ansonsten würde mir kein Grund für userdefinierte Ansichten einfallen.

[flaite]

Die ganze Theorie mit der Anordung der Daten einer GUI auf einem Screen ändert sich sowieso rasant.
Mit dem ganzen "mobile first" Thema und dieses tackelnde "responsive design", "adaptive design" werden nun Themen wie "Abstand zwischen Feldern, damit ich sie mit Fingerwischen auf Handy noch treffen kann" prominent. Da macht afaik jede nicht völlig vom Server entkoppelte Widget-Technologie (sprich reines JavaScript Framework) wie z.B. JSF-Primefaces die Grätsche. 

[jo@chim]

Soweit sind sie in unserem unterfänkischen Provinzweltkonzern noch nicht. Da nutzt nur das Top-Management Firmen-Tablets... und deren Anforderungen fallen für die Entwicklung in einem produktiven Umwelt g'ttlob nicht sonderlich ins Gewicht