Domino 9 und frühere Versionen > ND6: Entwicklung

Typisch Notes

<< < (6/8) > >>

koehlerbv:

--- Zitat von: MadMetzger am 04.03.07 - 22:53:26 ---@Bernhard: Das kann diese Klasse doch leisten. Die List enthält als Tag den Namen des Quellfeldes und der Eintrag zu dem Tag ist der des Zielfeldes.
--- Ende Zitat ---

Sorry, Markus, Du hast natürlich vollkommen Recht! Ich hätte schon genauer den Code lesen sollen ...

Norbert: Jo, die Sache ist nicht so einfach  ;)

Bernhard

Tode:
so, nachdem jetzt seitenlang dirskutiert wurde, wie man sowas in Script löst, nur eine kleine Bemerkung zur Lösung der Eingangsfrage:
Das neue Dokument übernimmt so lange die Werte vom "gewählten" Dokument aus der Ansicht, so lange das neu erstellte Dokument nicht gespeichert wurde.

Wenn man also so vorgeht:

Dok 1 erstellen, wenn Dok 2 erstellt werden soll, dann vorher Dok 1 speichern, dann klappts IMHO auch mit der Feld- Übernahme.

So 100% sicher bin ich mir dabei zwar nicht, aber mir wäre schon viel häufiger was in die Hose gegangen, wenn dem nicht so wäre...

Tode

flaite:
@Tode,

redest du nicht ein wenig am Thema vorbei?
Worum geht es hier?
Aus meiner Sicht darum, dass nur die Werte von bestimmten Feldern übernommen werden. Andere dagegen nicht. Und für flexible Lösungen hab ich bestimmte Probleme nachzuvollziehen, warum die hier vorgestellten Script Lösungen nicht effizient sein sollten.

Wenns in dieser Branche keine seitenlangen Diskussionen gäbe...
Wir hätten kein Springframework, kein Jboss, kein Hibernate, kein Groovy, kein Seams, kein .NET Forms, kein ASP.NET, kein Axis2. Kein better swing. Kein Eclipse. Kein Ajax. Kein Dojo, kein EJB3.

For a complex problem there is allways a solution which is neat, simple and plain wrong.

peace Axel

koehlerbv:
Torsten hat schon Recht - aber eigentlich sollte das auch klar sein. Ich bin bei einem CLI zumindest von dieser Kenntnis ausgegangen: In diesem Zusammenhang kommt ein ungespeichertes Dokument nicht in den unmittelbaren Fokus, ergo ... Ich bin daher auch erst an einem ganz anderen Punkt in die Diskussion eingestiegen (ich gehe bei sowas auch immer davon aus - wenn es denn abwendbar ist und nicht wie bei einem DocLink nun zwingend Speicherung erfordert - eine Speicherung auch vermieden werden kann).

Bernhard

flaite:
Eine Speicherung ist aber nicht immer zu jedem Zeitpunkt erwünscht.
Wenn z.B. Validierungsformeln gegen das geöffnete Dokument laufen.
Oder meinetwegen aus dem QuerySave eine Mail verschickt wird. Und für diese Geschäftslogik werden Daten aus dem anderen Dokument benötigt, das aus diesem Dokument heraus erzeugt wurde. In Anwendungen für den Browser ist zum Beispiel sogar sehr oft ein Speichern ziemlich problematisch.
Natürlich sollte man die Features, die die Plattform anbietet a) kennen und b) möglichst immer nutzen.
Es gibt manchmal Fälle, in denen die Geschäftslogik eben mit diesen Features nicht gut abbildbar ist.
Da ist es für einen Anwendungsentwickler immer gut, andere Wege zu kennen. Und die hier gemachten Vorschläge stellen aus meiner Sicht saubere Alternativen dar.
Wenn man auf Grund von technischen Details einer Plattform zu stark die Anwendungslogik unbiegen muß, spricht man von "intrusiveness of the platform".
Zugegebenermassen ist das nicht so einfach und da geb ich Tode mehr Recht als gestern abend. Klar gibts Fälle, in denen Leute ein in der Zukunft schwer wartbares Programmierfeuerwerk abfeuern, obwohl das gar nicht nötig ist. Oft führt das zu Kosten, die erst in der Zukunft aufschlagen. Besonders ärgerlich ist, wenn Leute das machen, weil das in irgendeiner Vorgängerversion mal nötig war und sich dann auch noch für Programmiergurus halten.
Manchmal muß oder sollte ich sogar auf jeder Plattform von den angebotenen eingebauten Features abweichen. Und da ist es immer gut, die Alternativen zu kennen. Und selbstverständlich auch die Kosten, die das möglicherweise in t1...tn erzeugt.
Intrusiveness of a platform ist natürlich nicht "Typisch Lotus Notes". Das gibts auch in Spring, Hibernate, EJB3, SOA, gute objekt-orientierte Praktiken or whatever. Nur macht mich auch dort die Kenntnis von Alternativen (und einer realistischen Einschätzung der daraus resultierenden Kosten) zu einem effektiveren Programmierer.

Gruß Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete