Also prinzipiell ist reflection ja ne feine Sache um Dinge zu generalisieren, aber in LotusScript offensichtlich nur mit "Stunts" möglich.
Da stimme ich zu. Aber du hast in LotusScript schlicht und ergreifend einfach nicht die Möglichkeiten, die du in Java hast. Also muß man sich da in der Praxis ein bischen anpassen.
In Java bin ich übrigens absolut der Meinung, dass solche Konstrukte:
Class charFilterClazz;
try {
charFilterClazz = Class.forName(clazzName);
instance = (CharFilter) charFilterClazz.newInstance();
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
throw new InstantiationError("Can not intantiate: " + clazzName, e);
} catch (InstantiationException e) {
// TODO Auto-generated catch block
throw new InstantiationError("Can not intantiate: " + clazzName, e);
} catch (IllegalAccessException e) {
// TODO Auto-generated catch block
throw new InstantiationError("Can not intantiate: " + clazzName, e);
} catch (ClassCastException e) {
throw new InstantiationError("Can not cast to CharFilter: " + clazzName, e);
}
nur so lange abgespaceter Guru-Zeugs ist, bis man es zum erstenmal einsetzt. Zumal das ganze Exception Handling eh von Eclipse generiert wird.
Das geht noch einen Schritt weiter als was du wolltest. Aber wenn noch nicht mal downKasten möglich ist, fehlt einfach in LotusScript die entsprechende Unterstützung.
Ich habe ein releativ komplexes Formular mit einigen Abhängigkeiten zwischen den zahlreichen Feldern. Ich möchte nun einen Wrapper um dieses Formular bauen wo ich die einzelnen Formularfelder nicht direkt über FieldGetText bzw. GetItemValue hole sondern über Getter Methode in einer Klasse eben. Die Felder sind über Properties gemappt. Korrespondierend soll es Setter Methoden geben mit denen die Felder befüllt werden.
Warum brauchst du da einen getter für? Ich komme OO-mässig auch eher von Java her bin aber gleichzeitig relativ erfahrener Domino Programmierer. Ich erlebe dass so, dass manche meiner Konstrukte einfach zu Java sind. Die klappen dann meist in LS nicht so gut. Wrapper ist z.B. etwas, dass sich irgendwie nie als sinnvoll erweist. Es liegt irgendwie auf der Hand. Klingt jetzt vielleicht ein bischen esoterisch.
Aber wieso brauchst du das?
Du kannst doch in die Mappings die realen Feldnamen reinschreiben?
Dann brauchst du keine extra getter und setter für.
[offtopic]
Ich hab sogar für das Übertragen von Feldwerten aus anderen Dokumenten eine Art mini-Konfigurationssprache entwickelt. Sieht dann so aus
Street=DBPersonal.LUPUser.KEY=userName.FIELD=Strasse.RESULTTYPE=String
Heisst:
Hole dir aus der Datenbank Personal
in der Ansicht User
mit dem Key des Wertes des Feldes userName des aktuellen Dokuments
den Wert des Feldes Strasse
mach es zu einem String
und fülle das Feld Strasse mit diesem Wert.
(wobei ich das mit dem RESULTTYPE erst nicht berücksichtigt habe. IST ABER WICHTIG).
Und natürlich stellt der kreative Teil der Kundenadmins Fragen, wie man an damit an die und jene Felder drankommt. Teilweise sprengt das dann den Rahmen des gegenwärtigen Frameworks. Ist ein interessanter Prozess. Leider inofiziell. Inofiziell ist ein anderes Wort für "generiert Überstunden".
[/offtopic]
Im Grund eignen sich für die Abarbeitung von sowas Notes-Klassen recht gut. Aber eben vielleicht anders als man erst denkt.
, kam mir die Idee für beide also NotesUIDocument und NotesDocument die gleichen Klassen mit den gleichen Properties zu verweden und sie lediglich anders zu initialisieren.
lohnt nicht. Du kannst ja im Aufruf des Konstruktors das UiDoc jederzeit zu einem Document machen.
new yourClass (uidoc.Document).
Das verkompliziert den Client Code wirklich nur sehr minimal.
Ball flach halten.
Gruß Axel
