Was ein Notes-Entwickler immer beachten/machen sollte

[TMC]

Hier hat es sich mal wieder gezeigt, dass es evtl. nicht schlecht wäre, eine Liste zu führen, was ein Notes-Entwickler generell immer beachten muss: Thread: DocLink in Sub Querysave

Hier mal der erste Anfang:

+ Immer Vorgabeansicht definieren
+ Option Declare nutzen in LS (kann in R6 der Prog.-Pane per Default gesetzt werden)
+ Code kommentieren
+ Debugger nutzen wenn LS-Code einen Fehler auswirft



Weitere Vorschläge sind willkommen. Vielleicht wird ja dann mal ein BP-Artikel daraus :-)

** EDIT **
10.06.04 19:30:
+ Errorhandling in Scripts verwenden (siehe BP-Thread)

[eknori]

+ Designer Help lesen
+ CACHE löschen und Rechner neu starten !
+ Knowledge Base lesen

[animate]

+ Knowledge Base lesen

aber nicht erst von eknoris Seite auf die eigene Platte ziehen!

[TMC]

+ @Author nicht verwenden (z.B. bei History)
+ Simple Actions in Agenten nicht verwenden (da Probleme vorprogrammiert)
+ RT-Felder soweit möglich immer vermeiden
+ sowenig Felder wie nur möglich in Masken
+ Scheduled Agenten mit kurzem Zyklus vermeiden
+ Sortierte Spalten vermeiden wo nicht unbedingt erforderlich

[animate]

was da in meinen Augen nicht fehlen soll, ist eine Begründung für die Aussagen.
Mir fällt es immer sehr schwer, irgendwelchen Geboten zu folgen, wenn ich nicht weiß, was dahinter steckt...

[TMC]

Klar, Thomas.

Ich stelle mir das so vor:
Eine Liste der ganzen Bedingungen/Aussagen. (also Inhaltsverzeichnis)

Und unten dann alles erklärt.
Also dann Details zur Vorgehensweise und Hintergründe warum das so ist.....

[animate]

hier sind ein paar ganz interessante Sachen dabei.
ist wahrscheinlich nicht so die Richtung, in die du mit diesem Thread wolltest, Matthias, ich finde jedoch, dass Teile daraus das Potenzial haben, eines Tages in den BP zu landen.

http://www.lotusgeek.com/SapphireOak/LotusGeekBlog.nsf/d6plinks/BLOT-5ZKNCH

[TMC]

hier sind ein paar ganz interessante Sachen dabei.
ist wahrscheinlich nicht so die Richtung, in die du mit diesem Thread wolltest, Matthias, ich finde jedoch, dass Teile daraus das Potenzial haben, eines Tages in den BP zu landen.

Danke, Thomas.
Passt denke ich gut sehr hier rein ;-)

[Glombi]

+ Simple Actions in Agenten nicht verwenden (da Probleme vorprogrammiert)

Die Dinger verwendet ein Entwickler NIE.

Was noch:
+ Systemansichten (versteckt mit runden Klammern) für Lookups etc. ; diese immer mit Alias
+ alle Masken erhalten Alias

Andreas

[Semeaphoros]

Begründung Andreas?

Ich sehe diese Behauptung immer wieder, bisher aber nie mit einer Begründung ..........

[Glombi]

Du meinst sicherlich die Aussage zu Simple Actions: Diese sind in erster Linie für Endanwender (ohne Programmierkenntnisse) gedacht, um mit ein paar Klicks brauchbare Aktionen zu basten.

Als Entwickler verwende ich die nicht bei der Programmierung, da
- keine Kommentare verwenden werden können
- die Wiederverwertbarkeit schlecht ist
- falls weitere Anforderungen kommen, die nicht mit Simple Actions möglich sind, muss alles mit Formelsprache oder Script neu gemacht werden. Also besser gleich damit.
- Bei so einfachen Sachen wie Feldwert ändern kann man nur statischen Text eingeben.
- sprachabhängig (erinnert mich an Notes 2, wo man noch @Wenn hatte  )

Insgesamt sind die Dinger nur statisch zu gebrauchen.
Es mag jedoch den einen oder anderen Fall geben, wo es auch vom Entwickler verwendet wird. Ich selbst habe das in den letzten Jahren aber nie gebraucht.

Andreas

[Semeaphoros]

Nein, nein, das mit den Simple Actions ist schon klar, die sind ja auch nicht für den Entwickler gemacht worden, sondern sollten dem Enduser die Möglichkeit geben, auch etwas zu machen. Ich meine die Aliase .... sorry, dass ich das vergessen hab zu sagen.

[Driri]

Was mir noch spontan einfällt :

@Today etc. in Views vermeiden wg. Performanceproblemen

[Glombi]

Gestaltungselemente sollten immer (sofern dies seitens Notes unterstützt wird) so aufgebaut werden:
<Benutzerschnittstelle>|<Programmschnittstelle>

<Benutzerschnittstelle> ist das, was Anwender sehen: Maskenname im Erstellmenü, Ansichten im Ansichtsmenü, Schlüselwörter in Auswahllisten

Zugriffen wird aber immer per Programmschnittstelle = Alias

Vorteile:
- Leichte Anpassungen kundenspezfischer Namensgebungen
- Leichtere Entwicklung von Anwendungen, die in Notes und Browser verwendet werden
- Leichtere Entwicklung von mehrsprachigen Anwendungen

Nachteile:
- höhere Tipparbeit

Andreas

[Glombi]

+ @Usernamen nur in privaten Ansichten

[Semeaphoros]

Ok, Aliasse für sichtbare Elemente haben den geschilderten Vorteil, das ist klar und richtig so. Du sprachst aber von Systemansichten und die werden ja eigentlich nur von Programmseite her angesprochen, da erübrigt sich das, weils nicht angepasst werden muss. Natürlich kann es vom Standpunkt der Lesbarkeit her gesehen trotzdem Sinn machen.

Meine Reaktion begründet darauf, dass ich schon mal jemanden schreiben gesehen habe:

"Der hat ja überhaupt keine Aliasse verwendet, was war denn das für ein stümperhafter Programmierer?" Das war eine Pauschalverurteilung, die man so sicher nicht aussprechen darf.

[Glombi]

Meine Systemansichten nenne ich immer so:

(<Name der Ansicht>) | <Name der Ansicht>

d.h. der Name wird eingeklammnert und ist daher nicht mehr sichtbar und der Alias erhält keine Klammern.

Das hat auch zur Folge, dass alle Systemansichten im Designer unter den sichtbaren Ansichten stehen.

Andreas

[TMC]

Schön, die Liste wird ja immer länger :-)

Was mir etwas unnötig erscheint: Für eingeklammerte Systemansichten Alias zu definieren: die Argumente von Andreas begründen das imho nicht, da eingeklammerte Ansichten ja eh nicht für den User sichtbar sind....
Oder gibt's da noch ein anderes Argument?

Ein paar hab ich noch:
+ Wenn Lotus Script - Shared Actions (insbesondere noch mit ScriptLib-Einbindung) erstellt werden sollen: den Code besser in einen Agenten auslagern - da ansonsten Probleme auftreten können und der Debugger u.U. nichts anzeigt
+ Einheitliche Variablen-Präfixe
+ LS sinnvoll splitten, wiederverwendbare Teile in ScriptLibraries auslagern

[eknori]

Klassenbildung bei längeren Libs - wenn nur eine Funktion/sub letztendlich gebraucht wird kann man da ne klasse Klasse draus machen; der Rest ist private ...

[TMC]

Hier auch noch ein netter Artikel, ein paar Dinge haben wir ja schon erwähnt  

http://www.chc-3.com/pub/tips1.htm