An dich hab ich gedacht, als ich den Link von Ed Brill entdeckt habe
Der hassenswerteste Satz war jener in dem verlinkten Duffbert Artikel:
"will allow a designer to use the forms paradigm to quickly develop J2EE applications without manually generating the vast array of J2EE code that is standard with most J2EE applications."
oder im Kommentar von Chris Reckling:
We're also providing a standardized way to deal with a document-oriented collaborative system, using XML and J2EE, while hiding some of the complexities of J2ee from the user.
... das schürt wieder diese Ignoranz.
J2EE Entwickler generieren hochkomplizierten Code von Hand und die Domino Smarties haben jetzt dieses brilliante Wundertool an der Hand. Schürt wieder Erwartungen.
Als ob es nicht andere Ansätze gäbe Dokument-orientierte Ansätze kollaborativer Systeme zu standardisieren. Oder auch andere Ansätze der automatischen code Generierung.
Wenn ich mir die Pläne zu EJB3 anschaue, dann sind da verdammt viele Ansätze von xDoclet, hibernate und vermutlich auch JDO und springframework verwurstet. Und jeder weiss es. Und jeder findet es gut, weil es dann übersichtlicher wird, weniger tippen und man vor bestimmten Komplexitäten geschützt wird.
Machen einen Mann zum SpecLead, der eine erfolgreiche EJB-Entity Beans Alternative entwickelt und designed hat, um ihr Zeugs einfacher zu machen und stellen sich dann hin, dass das andere alles sehr viel Hand-Coding beinhaltet und sie den Entwickler vor Komplexitäten schützen. Scheissendreck. Das tun alle anderen auch.
Das stört mich wahnsinnig an Lotus.IBM.
Auf Websphere.IBM werden solche fragwürdigen Angeberstatements nämlich einfach nicht gemacht.
Axel
überdies scheint das Startup Unternehmen "Deutsche Bank" hauptsächlich Studenten beschäftigen. Warum sonst sind ca. 50% der Artikel im dt. Javamagazin über Studenten-Alternativen mit einer Menge "Handcoding" (haha) wie struts und hibernate von Mitarbeitern dieses Unternehmens.