Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

RichTextItem direkt im Web darstrellen

<< < (3/4) > >>

flaite:
Kannst du mir mal bitte erklären, was du vorhast?
Beliebige Domino Dokumente in einer JSP Seite darstellen und dass sie gleichzeitig die Gestaltung der entsprechende Domino Gestaltung behalten.
Das geht so imnsho einfach nicht. Du müsstest von Websphere einen Direktzugriff auf die HTTP Engine von Domino haben.
Du könntest aus einem Servlet:
1. Eine HTTP Connection zum Domino aufbauen.
2. Dann bekommst du html.
3. Das html kannst du anzeigen. Irgendwie. HäHä. Einfach das html File auf Platte mit JSP Endung speichern und.... und ... und... einen Request Dispatcher drauf.
Freestyle. 

Das ist aber Schwachsinn, weil du keine akzeptable Performance hinbekommst.

Ich halte das für eine im Ansatz schlechte Idee.

Schon von der Projektidee.
Mein erstes Gefühl sagt mir immer: Was eine unglaubliche Arroganz. Da wird jahrelang über Design/Architektur von Integration von Backendsystemen ins Web öffentlich nachgedacht und derjenige, der sich das Projekt ausgedacht hat: Alles egal. Wir machen jetzt den gaaanz genialen Gedanken. Muß aber nicht richtig sein. Oder ich habe die Projektidee falsch verstanden.

Ich würd so vorgehen, dass ihr euch überlegt welche Daten ihr von Domino braucht. Von RDBMS, ein Modell. Frameworks. Alles andere endet imnsho meist schlecht.
Ich glaub man kann mit Portal Server auch irgendwie Domino Anwendungen auf Websphere bringen. Versuch das doch. Besser als mit einer Steinschleuder auf BrontoSaurier Jagd zu gehen.

flaite:

--- Zitat von: Gaert am 23.08.05 - 17:42:22 ---
Da ich aber nicht der Admin der Notes Datenbank bin, wäre es fatal das Auslesen der Felder zu hardcoden (Namen der Felder könne sich ändern, etc.).

--- Ende Zitat ---
Eigentlich sagt man, dass sich die Gestaltung eher ändert als die dahinterliegenden Backend-Strukturen. Und Domino ist hier Backendstruktur.
Wenn du z.B. mehrere Domino Datenbanken hast, die gegeneinander aufeinander zugreifen (kommt relativ oft vor), dann kann man meist auch nicht irgendwie fröhlich Felder ändern. Im übrigen: Sind nicht in einer Datenbank Feldnamen in Ansichten hartkodiert? oder in Skripten? Schreibst du z.B. in ein Querysave nie einen Feldnamen?

flaite:
Eine weitere Möglichkeit wäre:
Du holst dir das Domino Dokument per xml und wandelst es dann in einem Servlet oder mit Coocoon oder was auch immer in HTML um. Dann müsstest du nur das xslt für die Transformation umändern, wenn du ein Feld umänderst.
Aber deine Haltung zu "hartcodieren" geht mir irgendwie ein bischen zu weit. Felder haben eben Bezeichner.
Ich seh das immer ökonomisch. Felder haben Nutzen (man kann eine bestimmte Information punktgenau ansteuern) und Kosten (wenn sich die Feldnamen ändern, muß sich der zugreifende Code ändern). Das ist eben der Trade-Off. Wenn du die Kosten so hoch einschätzt und die totale Dynamik haben willst, mußt du eben auch auf den Nutzen verzichten. Und solche Radikalo-Rechnungen enden selten gut....

flaite:
Um die Anwendung von Änderungen in den ganz unten drunterliegenden Datensourcen zu ändern, gibt es verschiedene Wege.
Z.B. ein DAO Pattern. In meiner Hauptspielanwendung gibt es eine Reihe von Interfaces, in denen Methoden definiert werden, wie auf die Datenbank zu gegriffen wird. Ein Dao Pattern macht einen auch unabhängig davon, welche Datenbanktechnologie jetzt eingesetzt wird. D.h. man kann RDBMS durch Domino austauschen (zum Beispiel).

(z.B. updatePerson, updateMoneyPerson, insertPerson, selectPersonById, selectPersonByName, selectPersonByNameAndPassword, selectPersonsSortedByMoney, usw.)
Dann gibt es konkrete Klassen, die diese DAO Methoden implementieren. Diese benutzen SQL Befehle, die pro Interface in einer xml Datei stehen. Der konkrete Datenzugriff ist somit an einer klar definierten, leicht wiederzufindenen Stelle. Und alles läuft nach Schema-F und ohne ineffektive Kreativität. Für jede Methode des DAO Interfaces gibt es JUnit-Integrationstests. Dh.: Wenn sich etwas im Datenmodell ändert, rufe ich die Testsuite auf, die wiederum alle Testmethoden ausführt und dann bekomme ich gesagt, wo es knallt (Sofern meine Tests gut sind und sie sind es). Die JSPs greifen natürlich nicht direkt auf die DAOs zu, sondern sind nur für das Rendering der Html-Seite zuständig. Es gibt also noch eine Menge mehr. Eine Menge mehr.
Die ganze, nicht inkomplexe aber standardisierte und übersichtliche Infrastruktur wird von - hier - einer Menge openSource Frameworks unterstützt. Dh. die schwierigen Teile programmiere ich nicht selber, sondern ich baue auf der Arbeit von anderen auf.
Ich habe eine Reihe von gut orchestrierten Objekten mit klar definierten Verantwortlichkeiten. Dadurch lassen sich wirkliche Komplexitäten wie komplexere Transaktionen (ist eine Art Handelsplattform), Internationalisierung, unterschiedliche Clients, uvam leicht abfrühstücken.

Und das ist keine unnötige Komplexität sondern Wiederverwendung von Ideen of the human race.

Genau wie in Notes kann man eben in J2EE viel falsch machen, wenn man sich nicht entsprechend informiert. Ich persönlich mag auch moderne, auf J2EE aufsetzende "rebel frameworks" wie Springframework mehr als J2EE.classic. Sicherlich ist auch so etwas wie Ruby on Rails einen Blick wert. Nur ohne diesen Unterbau würde ich .NET programmieren.

Axel

Axel

flaite:
Es ist so gottverdammt hart und natürlich kann der Fragesteller mit dieser Antwort nicht viel anfangen.
Es ist aber the fucking Wahrheit:
Java ist eine Sprache, in der man eine Menge Hintergrundinfo benötigt, um damit etwas sinnvolles anzustellen. Und man muß sich in diesen Frameworks und Patterns auskennen. Sonst wird man nie fertig. Niemals.
So sehe ich das jedenfalls. Und ich bin da nicht alleine.
Das hat auch nix mit Arroganz oder so zu tun.

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete