Domino 9 und frühere Versionen > ND8: Entwicklung
Vorteile von Domino 8 als Webserver gegenüber Domino 7?
m3:
Was ich damals von der Lotusphere 2007 bezgl. Domino8/Webentwicklung mitgenommen habe:
--- Zitat ---# More development centric (some of this stuff is allready available in 7.0.2 but the sold it as „new in 8” ;) ):
1. Need to add attributes to the <html> tag? In Domino 8, just use the „$$HTMLTagAttributes” field.
2. Want to controll the doctype of the html-document and other „pre”-html-tag stuff? Use the „$$HTMLFrontMatter”. At last, we are able to „choose” the quirks-mode of the browser.
3. $$HTMLOptions controls HTML generation at the form or field level. Valid (name=value pairs) are RowAtATimeTableAlt, ForceSectionExpan, ForceOutlineExpand, DisablePassThruHTML and TextExactSpacing.
4. DisablePassThruHTML will be a way to prevent end-users from putting HTML tags into fields
5. There is JSON support in Domino 8 URLs!!! And word of mouth has it, that this also works in Domino 7 (try it out ;). Just add „$OutputFormat=JSON” to „?ReadViewEntries”.
See Codestore: Putting Domino’s JSON to Use for more details.
6. New C-API to allow stand alone applications to access Notes documents and get back HTML. There are also routines for accessing URLs. This will make Rod Boothby very happy. ;)
7. $Abstract – This field will hold the first n Bytes of Body field for display in a view
# Domino 8 will have an I/O reduction by 50% (no new hardware necessary?)
# New ODS version (optional on update) with these benefits:
* design document compression will lead up to 50 % smaller templates
* On demand Collations -> no additional view index for every sort-option in a view
* Enhanced User Activities
--- Ende Zitat ---
Ich bin aber noch nicht dazu gekommen, das auch mit der Realität zu vergleichen. ;)
flaite:
Danke.
1. Need to add attributes to the <html> tag? In Domino 8, just use the „$$HTMLTagAttributes” field.
AJ: Loseres Management der Domino HTTP Engine für den output. Für Leute, die sich mit Webentwicklung auskennen (völlig neutral gemeint).
2. Want to controll the doctype of the html-document and other „pre”-html-tag stuff? Use the „$$HTMLFrontMatter”. At last, we are able to „choose” the quirks-mode of the browser.
AJ: Loseres Management der Domino HTTP Engine für den output. Für Leute, die sich mit Webentwicklung auskennen (völlig neutral gemeint).
3. $$HTMLOptions controls HTML generation at the form or field level. Valid (name=value pairs) are RowAtATimeTableAlt, ForceSectionExpan, ForceOutlineExpand, DisablePassThruHTML and TextExactSpacing.
AJ: Loseres Management der Domino HTTP Engine für den output. Für Leute, die sich mit Webentwicklung auskennen (völlig neutral gemeint).
4. DisablePassThruHTML will be a way to prevent end-users from putting HTML tags into fields
AJ: Loseres Management der Domino HTTP Engine für den output. Für Leute, die sich mit Webentwicklung auskennen (völlig neutral gemeint).
5. There is JSON support in Domino 8 URLs!!! And word of mouth has it, that this also works in Domino 7 (try it out ;). Just add „$OutputFormat=JSON” to „?ReadViewEntries”.
AJ: Weiteres Format, um aus serverseitige Ressourcen aus JavaScript zuzugreifen. Für Leute, die sich mit Webentwicklung auskennen (völlig neutral gemeint).
6. New C-API to allow stand alone applications to access Notes documents and get back HTML. There are also routines for accessing URLs. This will make Rod Boothby very happy. ;)
AJ: Eher Webservice denn Webserver mässiges feature. Für Integration, nicht für Web-Design. Für C-API Programmierer.
7. $Abstract – This field will hold the first n Bytes of Body field for display in a view
AJ: Ermöglicht einfachere Benutzung von RichText-Feldern in Web-Ansichten.
# Domino 8 will have an I/O reduction by 50% (no new hardware necessary?)
# New ODS version (optional on update) with these benefits:
* design document compression will lead up to 50 % smaller templates
* On demand Collations -> no additional view index for every sort-option in a view
* Enhanced User Activities
AJ: Performance.
Interessant ist in diesem Zusammenhang auch diese Debatte: http://www.bobzblog.com/tuxedoguy.nsf/dx/who-uses-css-in-nd-apps-today?opendocument&comments#anc1
1999/2001 hab ich eine Menge Webentwicklung mit Domino gemacht. Damals hab ich das als 2 Schulen wahrgenommen (Aus meiner subjektiven Sicht: Ideologen und Pragmatiker, Good and Evil).
Die Ideologen beschäftigten sich nicht groß mit Webentwicklung. Sie hielten den Notes-Client für sowieso grundsätzlich überlegen. HTML/JavaScript Entwickler bezeichneten sie als Pixelschubser. Wenn man das braucht, wäre der HTTP-Task der Domino Engine völlig ausreichend. Der Rest wär eh nur unnötiges Beiwerk, das von irgendwelchen weltfremden Marketingabteilungen gefordert würde, die IT sowieso nicht verstehen und deshalb kein Recht haben, Anforderungen an IT zu stellen.
Die Pragmatiker hatten reale Kunden, die aus oft sehr vernünftigen Gründen ein Webfrontend wollten. Die beschäftigten sich mit css/javaScript, benutzten eine Menge passThru HTML, da sie wussten, dass es in der realen Welt oft die effizientere Lösung darstellte. Eine zentrale Seite war/ist Codestore.net.
Seh das so:
Die features von Domino 8 zeigen mir, dass Lotus zumindest jetzt davon abgegangen, HTML Generierung tightly selbst zu managen. Der zweiten Gruppe wird (endlich) mehr Raum gegeben. Die Features bringen nur Leuten was, die sich ohnehin schon intensiv mit Webprogrammierung beschäftigen.
flaite:
--- Zitat von: Mark³ am 27.09.07 - 10:11:29 ---vielleicht war meine Frage zu ungenau gestellt. Am Server an sich hat sich natürlich kaum was geändert. Da aber alle Anwendungen auf einem Domino 8-Server natürlich auch mit einem 8er-Client entwickelt werden könnten, hätte ich evt. viel mehr Möglichkeiten, eine Datenbank, die momentan für den 6.0er Notes-Client entworfen ist, im Web anzubieten. Insofern wären die Webservices schon einmal ein Punkt O0
--- Ende Zitat ---
I have to insist. Consumer Web Services sind dafür da, um mit Domino als Consumer/Client auf Daten von anderen Backend-Systemen zuzugreifen. In meinen Fall waren das bisher SAP und die Factiva Services von Dow Jones.
Mark³:
der gute Jake Howlett ist mein Vorbild, was Notes-Webentwicklung angeht. Das ganze losere Management für HTML-Output benötige ich allerdings nicht unbedingt. Ich mache momentan schon viel mit Scriptaculous und AJAX-Agents. Bis jetzt habe ich kein konkretes Problem, wo ich unbedingt einen bestimmten Modus (oder keinen Quirks) im Browser benötige.
Allerdings habe ich etwas Befürchtungen, was passiert, wenn ich nicht 5 AJAX-Webapps habe, sondern 150 auf einem Server. Wenn dann jede DB in jeder Maske für jede Aktion einmal einen Agenten über AJAX aufruft, wird das dann vielleicht kollabieren? Natürlich habe ich 'concurrent web-agents' aktiviert, aber irgendwo ist sicherlich auch hier mal die Grenze errreicht, wo der Server noch performant arbeitet. Gibt es eine Begrenzung, wieviel Webagents max. concurrent laufen dürfen?
Naja, und Webservices werde ich wohl auch nicht nutzen, da es nur darum geht, die bestehenden DBs so einfach wie möglich webfähig zu machen.
flaite:
--- Zitat von: Mark³ am 27.09.07 - 14:13:19 ---Allerdings habe ich etwas Befürchtungen, was passiert, wenn ich nicht 5 AJAX-Webapps habe, sondern 150 auf einem Server. Wenn dann jede DB in jeder Maske für jede Aktion einmal einen Agenten über AJAX aufruft, wird das dann vielleicht kollabieren?
Natürlich habe ich 'concurrent web-agents' aktiviert, aber irgendwo ist sicherlich auch hier mal die Grenze errreicht, wo der Server noch performant arbeitet. Gibt es eine Begrenzung, wieviel Webagents max. concurrent laufen dürfen?
--- Ende Zitat ---
Hängt natürlich auch davon ab, was die Agenten machen. Die Grenze ist aber irgendwann sicher da. Mich beunruhigt das definitiv. Versuch alles was ich machen kann (z.B. caches in javaScript). In Java-Land werden die Servlets-Engines so umprogrammiert, dass die viel mehr einkommende Requests unterstützen können.
http://docs.codehaus.org/display/JETTY/Continuations
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln