Domino 9 und frühere Versionen > ND6: Entwicklung

[LotusScript] Type Mismatch

<< < (3/6) > >>

koehlerbv:

--- Zitat von: TMC am 01.03.05 - 19:20:22 ---Und noch zur Ergänzung:
Ich würde immer doc.GetItemValue nehmen, und die "Extended class" Syntax (doc.Itemname) mir gar nicht erst angewöhnen, auch wenn es bequemer erscheint.
Grund:
[*]Performanceeinbußen (soll massiv sein, hab ich zumindest mal gelesen, leider keine Quelle mehr parat)
[*]Probleme, wenn der Itemname = einer Notes-internen Bezeichnung entspricht
[*]Du kannst den Itemnamen auch als String (Variable oder Konstante) übergeben.
[/list]

--- Ende Zitat ---

Dazu folgende Anmerkungen:
- Die Quelle würde mich auch interssieren !
- NotesItem = Intern verwendete Konstante: Das sollte man sowieso und immer vermeiden.
- Itemname als Variable: Jo, das hat was.

Wegen den Performance-Einbrüchen: Da der Zugiff auf Items von Dokumenten ja immer das Lesen von Platte bedeutet, ist diese Umsetzung (die sowieso schnell bei der selben API-Routine wie GetItemValue landen wird) im RAM eine vernachlässigbare Grösse. Ich habe dazu (als das auch hier im Forum schon mal hochkochte) mal Tests gemacht: Die Ergebnisse waren nicht signifikant (mal war das eine etwas (!) schneller, mal das andere. Und da ging es um Zugiffe auf Items aus > 50.000 Docs.

Bernhard

EDIT: Es sei aber auch darauf hingewiesen, dass von Lotus / IBM gelieferte Schablonen in der Regel mit GetItemValue etc. hantieren und nicht mit der Kurznotation.

TMC:

--- Zitat von: koehlerbv am 01.03.05 - 19:37:55 ---- NotesItem = Intern verwendete Konstante: Das sollte man sowieso und immer vermeiden.

--- Ende Zitat ---

Ich denke Du meinst NotesItemName. Unter manchen Umständen kann das durchaus praktikabel sein, den Namen eines Items als Konstante zu definieren, z.B. innerhalb einer ScriptLibrary, die z.B. auf (Teil-)Masken verweist, welche immer wiederkehrende Items enthält (Lösch-Flag, Historie, etc. etc.). Sollte sich der Itemname ändern: -> Anpassung an 1 zentralen Stelle.

Ich muss nochmal wühlen bezügl. des Performance-Problems. Aber der Artikel den ich dazu mal gelesen hatte, klang sehr überzeugend. Es ging speziell um das Auflösen (Also die Abfrage: "ist das nun ein Itemname oder passiert da was mit einer Methode/Property. Wenn Itemname, dann kippen wir das ganze mal in GetItemValue").

Erwähnenswert für DaWutz ist auch noch in dem Kontext, dass bei Itemnamen, die ein vorangestelltes $ haben (z.B. $REF), ein ~ vorangestellt werden muss bei der Extended Class Syntax (z.B. doc.~$REF).

Marinero Atlántico:
Bzgl. der Performance stimme ich mit Bernhard überein.
Die Literatur rät dazu, dass Performance-Optimierungen immer auf ein Ziel hin gerichtet sein sollen.
Also für Notes: Das Querysave dieser Maske darf auf der und der Standardhardware nicht länger als sagen wir 0.5 Sek. dauern. Wenn ja, muss optimiert werden.
Hier nicht unbedingt aber performance-optimierter code kann schnell auch gleichzeitig nicht so übersichtlicher code sein. Und man sollte nur dort optimieren, wo es einen Mehrwert für den Anwender verspricht.
Ob ein Skript jetzt 0.680 oder 0.681 sek dauert, ist nicht so interessant.

Aber - wie Mathias schon im Kontext von "Konstante" angedeutet hat - hat getItemValue den Vorteil, dass es parametrisierbarer ist. Ich benutz das oft, wenn es darum geht eine Reihe von Feldern eines docs zugreifen muss. Nur dann schreib ich es in einen Array und tue diesen nach oben im Skript.
Es gibt auch manchmal Situationen, wo man diese Feldnamen sinnvoll in ein externes Konfigurationsdokument externalisieren kann. Nur kann man es damit auch übertreiben.

TMC:

--- Zitat von: Marinero Atlántico am 01.03.05 - 20:06:01 ---Bzgl. der Performance stimme ich mit Bernhard überein.
Die Literatur rät dazu, dass Performance-Optimierungen immer auf ein Ziel hin gerichtet sein sollen.
Also für Notes: Das Querysave dieser Maske darf auf der und der Standardhardware nicht länger als sagen wir 0.5 Sek. dauern. Wenn ja, muss optimiert werden.
Hier nicht unbedingt aber performance-optimierter code kann schnell auch gleichzeitig nicht so übersichtlicher code sein. Und man sollte nur dort optimieren, wo es einen Mehrwert für den Anwender verspricht.
Ob ein Skript jetzt 0.680 oder 0.681 sek dauert, ist nicht so interessant.
--- Ende Zitat ---

Guter Einwand, Axel.
Zumal ich ja auch sehr oft die Extended Class Syntax verwende  :P
Aber ich will DaWutz gleich mal in die richtige Richtung weisen, sonst haben wir noch morgen einen Thread von ihm, warum {doc.Authors = "Hans Huber/Org"} nicht funktioniert  ;D

Den Artikel hab ich leider jetzt nicht gefunden, aber der Performance-Einbruch klang bemerkenswert.

Feldnamen in Konfig-Dokumenten: Wenn dann nur vorgegeben: nicht änderbare Liste mit festen Vorgabewerten. Keinesfalls sollte man das frei definierbar machen, da IMHO Konfig-Doks nicht für Entwickler, sondern für Admins und/oder Endanwender sind. Da würde ich allerhöchstens auswählen lassen: Schreibe XY in Item A oder Item B.

Glombi:
Leider finde ich den Artikel auch nicht, aber ich kann mich erinnern, dass die Performance der Extended Class Syntax signifikant schlechter ist.

Im net habe ich das hier bei der ersten Suche gefunden:
http://www.martinscott.com/home.nsf/0/C7F5B845A9E6C76385256C180007FBEF?opendocument

einiges davon stammt wohl hieraus:
http://www-12.lotus.com/ldd/doc/bp/46bpg.nsf/

Bemerkenswert u.a.:
Using the ColumnValues property is about 10 percent faster than getting a handle to a document and using the extended class syntax-- e.g., x=doc.fieldname.


Andreas

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete