generelle Architektur Fragen

[ARadauer]

Ein alter Freund von mir hat einen Taxi und Limousinen Service. Der hätte gerne ein Software Tool zum Verwalten von Kunden, Aufträgen, Rechnungen, Dienstplanung... eine nette Verwaltungssoftware. Ich würde nun eine Desktopanwendung mit Swing schreiben, die auf eine entfernte mysql datenbank zugreift. Zusätzlihc hätte er gerne eine Webgui in der er gewisse Auswertungen machen kann bzw Dienstpläne betrachten kann.

Wie würdet ihr das realisieren? Das wär doch ein klassisches Lehrbuchbeispiel für EJBs oder? Webanwendung (JSP, Servlets) greifen auf EJB zu. Desktop Anwendung greift auf EJB zu. EJB greift auf Datenbank zu.

Jedoch hab null Erfahrung mit EJB, ich bin mir nicht sicher ob das nicht der totale overkill ist. Mir steht zur Zeit auch kein Anwendungsserver zur Verfügung. Ist es sinnvoll, die Webgui zb über PHP zu machen und direkt vom Web und Desktop auf die Db zuzugreifen. Also das Teil müsste jetzt nicht massig skalierbar sein. Das wird maximal von 5 Benutzer genutzt.

Ich müsste dann halt gewisse Logiken zweimal programmieren.
Wär es vielleicht sinnvoll einen Webservice dazwischen zu schalten?

Wie viel Zeit würdet ihr ungefähr für so ein Projekt schätzen? 5-7 Fachobjekte (Kunden, Destinationen, Aufträge, Fahrer, Fahrzeuge,...)
Kundenverwaltung, Destinationsverwaltung, Aufträge erstellen, Rechnungen erstellen, Rechnungsdruck, Umsatzauswertung, Dienstplan...
Also is sicher schwer zu sagen, die Anforderungen sind auch noch nicht genau definiert, aber ungefähr?

 

[tfa]

Warum überhaupt eine Swing-GUI? Beschränk Dich doch auf eine Web-Anwendung. Oder verlangt der Kunde auch ein Desktop-Programm?

 

[SnooP]

Ich würde den pragmatischeren Ansatz nehmen und Spring verwenden und nen sauberes Modell vorlegen, anstatt sich in die Konfigurier-Hölle EJB zu wagen

aber trotzdem ist tatsächlich die Frage, ob man nicht statt Swing doch lieber komplett Web machen sollte... mag ich persönlich ja lieber

 

[ms]

Jedoch hab null Erfahrung mit EJB, ich bin mir nicht sicher ob das nicht der totale overkill ist.

Naja, overkill ist es schon. Wenn du es aber gleichzeitig für dich als Lernprojekt siehst und der Kunde (dein alter Freund) auch geduldig ist, dann ist es schon ok.

ms

 

[ARadauer]

danke für die antworten:

@ms: wär sicher ganz nett, wenn ich dabei ejb lernen könnte. jedoch steht das ganze doch unter einem gewissen zeitdruck. und da ich das nach der arbeit mache und ich sowieso den ganzen tag programier, würd ich doch gerne auf meine skills setzen

@Snoop: wär natürlich sinnvoll das ganze als webprojekt zu realisieren. wobei ich sehr gerne und doch schon sehr gut mit swing arbeite. beim nächsten projekt hier in der arbeit wird auch spring eingesetzt werden, von dem ich noch wenig ahnung habe, da ist es sicher sinnvoll, wenn ich mich vorher schon mal in einem privaten projekt damit beschäftigt habe.

und wie seht ihr das zeitlich? wie lange würdet ihr für sowas ungefähr brauchen?

 

[SnooP]

Ich persönlich finde halt, dass man in Webprojekten schneller einfache GUIs entwickeln kann mit einem sauberen MVC, als bei Swing-Anwendungen... zumindest hat man nen sehr viel strikteres Vorgehensmodell und muss sich diesem ziemlich unterwerfen... bei Swing bzw. RCs muss man disziplinierter sein

 

[HLX]

Wenn dein Kumpel ein großes Filialnetz seines Limousinenservice mit 2-3 Zentralen aufgebaut hat, dann kannst du mal über EJB nachdenken. Für ein kleines Einzelunternehmen ist das quatsch.

Ob neben der Web-GUI noch eine Swing-GUI sinn macht, hängt von den Anforderungen an die Oberfläche ab.

 

[maki]

Kann mihc da meinen Vorrednern nur anschliessen.
Ohne Zeitdruck machst du es halt mit EJBs und JSF, mit Zeitdruck eher Swing.
Denn wenn man einen Termin hat, sollte man Lösungen bevorzugen, die man beherrscht.

 

[ARadauer]

Ok danke für eure Ratschläge, hört sich sehr logisch an. Ich werd die Sache mittels einer Webanwendung realisieren.

Vorschläge für Frameworks? Spring in Verbindung mit Struts und Hibernate ist wahrscheinlich nicht verkehrt, oder?

 

[bronks]

... Vorschläge für Frameworks? Spring in Verbindung mit Struts und Hibernate ist wahrscheinlich nicht verkehrt, oder?

Wozu der ganze Unfug? Nimm einfach die klassischen Patterns und setzte damit Dein Programm zusammen. Webgui dazu mit JSF und alles paßt.

 

[ms]

... Vorschläge für Frameworks? Spring in Verbindung mit Struts und Hibernate ist wahrscheinlich nicht verkehrt, oder?

Wozu der ganze Unfug? Nimm einfach die klassischen Patterns und setzte damit Dein Programm zusammen. Webgui dazu mit JSF und alles paßt.

Unfug?
JSF durch Struts ersetzen ist ok, aber persistieren wäre auch nicht schlecht.
Und mit Spring kann man einige "klassische Patterns" sehr schön umsetzen.

ms

 

[SnooP]

Spring, Struts, Hibernate klingt sehr gut... - wenn du geil bist, nimm gleich Struts2... wenn du noch geiler bist ... vielleicht sogar JSF. Da ist die Einarbeitungszeit vermutlich aber noch etwas höher.

Spring+Hibernate ist schon nen ziemlich gutes Team und erleichtert das Bauen von DAOs - echt ne schöne Sache.
Bei Hibernate würde ich gleich den JPA-Ansatz - sprich Annotations nehmen - du wirst es nicht bereuen

 

[maki]

Spring+Hibernate ist schon nen ziemlich gutes Team und erleichtert das Bauen von DAOs - echt ne schöne Sache.
Bei Hibernate würde ich gleich den JPA-Ansatz - sprich Annotations nehmen - du wirst es nicht bereuen icon_wink.gif

Mit EJB 3.0 und JPA+Hibernate spart man sich die DAOs, die werden mitgeliefert und vom Entitymanager weg-abstrahiert

 

[happy_robot]

Warum überhaupt eine Swing-GUI? Beschränk Dich doch auf eine Web-Anwendung. Oder verlangt der Kunde auch ein Desktop-Programm?

Wieso glaubt eigentlich jeder daß man alles als Web-Anwendung machen kann? Wenn er seinem Freund einen Gefallen "tun" will dann sollte er es als Fat-Client implementieren. Spätestens wenn's ums drucken geht wird er feststellen daß ein Fat-Client besser gewesen wäre. Die Notwendigkeit für eine Web-Anwendung sehe ich auch nirgendwo.

Ok danke für eure Ratschläge, hört sich sehr logisch an. Ich werd die Sache mittels einer Webanwendung realisieren.

Leider lässt man sich ja gerne so was schnell aufschwatzen

Allerdings vermute ich auch daß Du den Aufwand vielleicht deutlich unterschätzt, egal ob Web-Anwendung oder Fat-Client.

 

[happy_robot]

JSF durch Struts ersetzen ist ok, aber persistieren wäre auch nicht schlecht.

ich will ja nich meckern, aber das eine hat mit dem anderen recht wenig bis gar nix zu tun.
die entscheidung sollte imho hier ganz klar auf JSF fallen. struts ist doch mittlerweile ein totes projekt. es war sicherlich lange die erste wahl, aber wenn er nicht nur seinem kumpel nen gefallen tun will sondern auch sich dann sollte er JSF einsetzen.

 

[ms]

JSF durch Struts ersetzen ist ok, aber persistieren wäre auch nicht schlecht.

ich will ja nich meckern, aber das eine hat mit dem anderen recht wenig bis gar nix zu tun.

Richtig, deswegen hab ich das ja auch geschrieben. Die Daten müssen ja auch irgendwo liegen.

Übrigens, im ersten Post war ganz klar von einer Web-Gui für Auswertung und Anzeige die Rede.

ms

 

[bronks]

Edit: Hab den Text gelöscht, denn er war nur dafür ausgelegt den MS zu ärgern. Sorry, MS!

 

[happy_robot]

Übrigens, im ersten Post war ganz klar von einer Web-Gui für Auswertung und Anzeige die Rede.

er fragt im ersten post ob es sinnvoll ist. und nein, für das was er machen will ist es imho nicht sinnvoll.

 

[ms]

Zusätzlihc hätte er gerne eine Webgui in der er gewisse Auswertungen machen kann bzw Dienstpläne betrachten kann.

ms

 

[happy_robot]

Zusätzlihc hätte er gerne eine Webgui in der er gewisse Auswertungen machen kann bzw Dienstpläne betrachten kann.

ms

stimmt. hatte ich überlesen.

ich glaube nun aber tatsächlich daß das ganze deutlich mehr als ein "gefallen" wird.

 

[byte]

Spätestens wenn's ums drucken geht wird er feststellen daß ein Fat-Client besser gewesen wäre.

Das musst Du mir mal näher erläutern. Was hat Drucken mit der Entscheidung Fat vs Thin Client zu tun? Es ist doch völlig irrelevant, wie die GUI gemacht ist - Du transformierst die Daten in ein druckbares Format und fertig.

 

[happy_robot]

Das musst Du mir mal näher erläutern. Was hat Drucken mit der Entscheidung Fat vs Thin Client zu tun? Es ist doch völlig irrelevant, wie die GUI gemacht ist - Du transformierst die Daten in ein druckbares Format und fertig.

kennst du irgendeine professionelle anwendung die aus dem IE heraus druckt? also mal ehrlich. wenn ich mit so etwas arbeiten müsste würde ich's zurückgeben.
und was kommt als nächstes? online-textverarbeitung im IE 7? eclipse als web-app?

wenn man vernünftig mit etwas arbeiten will kommt man um einen fat-client nicht rum. dieses web-app-gefummel taugt nix für so was. für kurze ansichten evtl auch kleinere dateneingaben ist's ok, aber ich denke daß das was da eingegeben werden muss umfangreicher ist als "Name, Adresse, Telefonnummer". wenn da jeder mist erst 10x online validiert werden muss vergeht einem schnell die lust. da hilft auch AJAX nicht wirklich.

 

[byte]

kennst du irgendeine professionelle anwendung die aus dem IE heraus druckt?

Klar kenne ich das. Aber natürlich druckt man nicht die HTML-Seite über den Browser aus. Du transformierst die Daten in ein Druckformat (z.B. PDF) und schmeisst das in den Response. Das ist bei Fat Clients im übrigen nicht anders oder druckst Du etwa z.B. einen JTable direkt aus?

und was kommt als nächstes? online-textverarbeitung im IE 7? eclipse als web-app?

Du scheinst irgendwie nicht ganz auf dem Laufenden zu sein, was webmäßig so alles möglich ist, siehe z.b.:
http://docs.google.com/

 

[happy_robot]

aha.....also bevor man was drucken will muss man sich das erstmal runterladen und dann aus'm adobe heraus drucken...

bekannte praxis bei online-rechnungen, verdient aber für die gewünschte anwendung im praxisgebrauch wohl eher nur ein lächeln. usability is' wohl eher suboptimal.

und deine empfehlung kenne ich auch bereits, allerdings eher von portalservern und deren CMS-portlets. es ist eher ein krampf damit zu arbeiten. für 1-finger-adler-suchsystem noch gerade so verträglich. mit 10 fingern musst du so viele pausen einlegen daß es auch hier eher als unbrauchbar anzusehen ist. die hälfte wird dann vergessen, wenns nicht gerade noch im 13-zeichen-tastaturpuffer hängt.

die entwicklung bremst sich hier meiner meinung nach selber. alle wollen das ziel erreichen daß eine web-app das kann was ein fat-client schon jahre kann. wofür brauchen wir dann noch 3Ghz am desktop? oder gar quadcore? man geilt sich hier an etwas auf was schon jahrelang in fat-clients bekannt ist. nur weil es eine web-app ist.....

das problem ist daß viele software-schmieden einfach keine leute mehr haben die fat-clients entwickeln können. da wird sich dann hier und dort einer abgebrochen und man freut sich dann ganz dolle über eine progressbar die sich im IE bewegt.....

 

[byte]

Das ist Deine Meinung, sie muss aber nicht umbedingt die richtige sein. :roll:
Vor- und Nachteile von Thin gegenüber Fat Clients wurden schon oft genug diskutiert. Das brauchen wir an dieser Stelle nicht schon wieder tun.

 

[happy_robot]

Das ist Deine Meinung, sie muss aber nicht umbedingt die richtige sein. :roll:

für diesen anwendungsfall scheint es mir aber die einzig richtige zu sein. wie er es macht ist mir eigentlich wurscht.

Vor- und Nachteile von Thin gegenüber Fat Clients wurden schon oft genug diskutiert. Das brauchen wir an dieser Stelle nicht schon wieder tun.

es ging nicht um vor- und nachteile. es ging um die grundsätzliche entscheidung wie er das umsetzen soll. und hier spricht vieles für nen fat-client.

mich kotzt nur diese blauäugigkeit von "web-entwicklern" an die immer meinen daß man alles ganz doll als web-app machen kann und die es dann dem umfeld auch noch als sinnvoll verkaufen. das glaubt leider jede zweite von halbwissen durchtränkte webfummel-software-schmiede. da wird der letzte mist als web-app verkauft nur damit man nen auftrag kriegt. der kunde bleibt auf der strecke und fühlt sich nur gut weil er ein heiden-geld dafür bezahlt hat (oder besser: aus dem fenster geschmissen hat).

dass geht jetzt nicht konkret gegen jemanden, also nicht falsch verstehen.

zur zeit sitze ich z.b. in einer firma die ein produkt verkauft daß es noch gar nicht gibt...es gibt nicht mal ein design...nur plakate, pseudo-screenshots, nen click-dummy und 5 vertriebs-deppen die das anpreisen......es steht nur fest daß es ne web-app mit AJAX sein muss. sinn macht's keinen, und alle entwickler hier sehen es so daß es nur als fat-client brauchbar ist. die chefs sehen es anders: web-app is' modern, lässt sich besser verkaufen.....

 

[ms]

So ganz happy scheinst du ja nicht gerade zu sein, wie dein Name vermuten lässt.
Aber dein Problem kenne ich, da kann man als Entwickler nicht viel machen wenn ein paar hypergeile Marketingheinis sich was in den Kopf gesetzt haben und nur $$ in den Augen haben.
Andererseits, wenn man die Applikation halbwegs sauber designed, die Schichten schön trennt, dann ist es (fast) nur mehr die Client/Webschicht von der wir hier reden.

Und PDF als Druckformat fürs Web ist heute quasi Standard.

ms

 

[happy_robot]

So ganz happy scheinst du ja nicht gerade zu sein, wie dein Name vermuten lässt.

eigentlich schon :lol: nur die gewissheit daß man wahrsacheinlich wieder fehlentscheidungen anderer hinterherhackert die dann eh irgendwann eingestampft werden trübt meine stimmung ein wenig.

Aber dein Problem kenne ich, da kann man als Entwickler nicht viel machen wenn ein paar hypergeile Marketingheinis sich was in den Kopf gesetzt haben und nur $$ in den Augen haben.

die haben ja ihr "gespür" nicht von sonst wo her. es wird ihnen ja auch so erzählt. ob dieses oder jenes sinn macht wird nicht überlegt. zählt ist das was modern zu sein scheint.

Andererseits, wenn man die Applikation halbwegs sauber designed, die Schichten schön trennt, dann ist es (fast) nur mehr die Client/Webschicht von der wir hier reden.

viel mehr ists eh nicht.

Und PDF als Druckformat fürs Web ist heute quasi Standard.

habe ich nicht geleugnet. allerdings schwebt mir hier eher in dieser anwendung der vollautomatische ausdruck vor, ohne rumgeklicke und abhängigkeiten zu weiteren applikationen. es würde hier schon am "vollautomatischen ausdruck" scheitern. format wäre mir total wurscht.

 

[SnooP]

Wenn man irgendwas automatisch drucken will - klaro... muss man halt nen Fat-Client nehmen... - aber mal ehrlich - das gesamte Druck-Handling ist in Java ja wohl eher suboptimal gelöst

und Struts tot? ... naja... totgesagte leben länger? Aktuell wird auf jeden Fall noch mehr mit Struts als mit JSF gemacht - und persönlich denk ich auch, dass Struts 2 bewusst runtergeredet wird.

Ich find persönlich Webanwendungen halt einfach besser zu entwickeln, weil die Präsentationsschicht ein sehr viel einheitlicheres Prozedere zulässt... - auch der Umgang mit Hibernate ist quasi vorgegeben

und es ist weitaus weniger nervig... find ich halt... ich baue hier mit ramdösigen Layoutmanagern dumpfe Masken zusammen mit dümmlichen Property-Change-Mechanismen und muss mich mit Hinterlassenschaften von noch ramdösigeren Vorentwicklern rumärgern, die von MVC augenscheinlich noch nix gehört hatten...

Trotzdem hast du natürlich auch recht... bestimmte Sachen sind einfach nur via Rich-Client zu erledigen. Aber bestimmte Vorteile hat ne Webapp halt auch immer ... z.B. das einfachere Deployment und der schnelle Zugriff von überall aus.

 

[ARadauer]

Find solche Diskussionen sehr interessant.


Ich denke nicht, dass ich den Aufwand unterschätze. Eher das mein Freund den Aufwand unterschätzt. Es heißt ja nicht, dass der Gefallen gratisch gemacht wird. Nach dem ich ihm meine Preisvorstellung mitgeteilt habe, haben wir mal die Funktionen reduziert. Aber mit dem hab ich gerechnet.

Ich werde doch eine Swing Anwendung machen.
Ich bin in Swing schneller. Ich bin da sehr rutiniert. Bei einer Webanwendung würd ich viel länger brauchen.
Die Idee von Auswertungen übers web ist meinm Kumpel aus dem Grund gekommen, da er von Unterwegs mit dem Laptop gewisse sachen machen möchte. Aber ehrlich ob Web oder Desktop Anwendung is dann ja egal, denn er hat die Anwendung sowieso am Laptop.

naja mal schaun, wär natürlich nicht schlecht, wenn ich mich mehrmit webanwendungen beschäftigen würde, jedoch hab ich mir grad eine eigentumswohung gekauft und die macht auch einiges an arbeit...

 

[robertpic71]

ARadauer:
Ich finde die Entscheidung aus deiner Sicht 100% richtig. Gerade bei privaten Projekten (nicht nach stundenbasis) sollte der Aufwand gut kalkulierbar sein, damit man am Ende nicht mit einem Hungerlohn dasteht. In deinem Fall ist halt die Swinglösung kalkulierbarer - was ja eine spätere Webabfrage nicht ausschließt.

Zur Diskussion FatClient vs. Webanwendung:
Ich habe bis vor 1-2 Jahre Webanwendungen für bestimmte (tastaturintensive) Anwendungen ausgeschlossen. Aber Dank AJAX ist es jetzt auch möglich 100% tastaturbedienbare Anwendungen für z.B. Telefonverkäufer zu machen.

Es gibt mittlerweile auch schon viele Ajax-Frameworks, welche einem mächtige Komponenten liefern und Javascript vom Leib halten. Eines davon ist ZK, einen Vergleich mit JSF und Struts gibt es hier. Ich finde vorallem die Lernkurve viel flacher als bei JSF und Struts. Es gibt zwar auch einen GUI-Designer, der ist aber noch nicht wirklich brauchbar...

Und PDF als Druckformat fürs Web ist heute quasi Standard.

habe ich nicht geleugnet. allerdings schwebt mir hier eher in dieser anwendung der vollautomatische ausdruck vor, ohne rumgeklicke und abhängigkeiten zu weiteren applikationen. es würde hier schon am "vollautomatischen ausdruck" scheitern. format wäre mir total wurscht.

Ich kenne das, in der Firma haben wir ein paar Speditionsabindungen. Die Pakete/Paletten werden via Browser eingegeben, dafür bekommt man ein PDF (Etikett), welches man downloaden, öffnen und ausdrucken darf.

Vor 2 Tagen haben wir eine neue Webanwendung einer Spedition (Traussnig) in Betrieb genommen. Die Anwendung selber besteht hauptsächlich aus JSP-Seiten. Angereichert wird das ganze aber um 2. Applets:
1. liest die Namen der lokalen Drucker aus, damit den Etikettendrucker angeben kann (einmalig)
2. druckt das Etikett am lokalen Drucker aus - ohne irgendwelche zusätzlichen Dialoge

Der Arbeitsplatz bei uns ist ein X-Windows-Terminal an einem Debianserver. Der Drucker ist im Cups definiert - funktioniert alles bestens (natürlich auch unter Windows).

/Robert

 

[happy_robot]

Aber Dank AJAX ist es jetzt auch möglich 100% tastaturbedienbare Anwendungen für z.B. Telefonverkäufer zu machen.

AJAX ist auch wieder ao ein komisches "ding". statt generell zu überlegen wie man die viewer (also den browser) um sinnvolle native funktionalitäten und schmale interfaces zu erweitern wird dann so ein ding wie AJAX geboren nur weil sich mal wieder keiner traut den pionier zu spielen. damit wird sich dann an pseudo-fat-funktionalitäten herangefummelt und einfache seit jahren bekannte funktionalitäten sind das höchste glück des hackers.
einmal auf den zurück-button geklickt oder aus versehen auf BSP und ein grossteil aller super-dollen AJAX-anwendungen kommen total durcheinander. design-technisch gehört der ganze web-kram komplett in die tonne.

allerdings weiß ich auch nicht so recht was AJAX mit 100%tiger-tastatur-bedienbarkeit zu tun hat ???:L . nem onchange-listener ein submit zu verpassen ging schon lange vor AJAX. nun ja......ich will nicht zynisch sein, aber mit der definition und dem verständnis von AJAX ist's ungefähr so weit her wie mit dem begriff "Web 2.0". jeder benutzt es, aber keiner weiß was es ist.

mein chef "erkennt" eine AJAX-anwendung z.b. pauschal daran wenn sich irgendwie etwas bewegt. die ganze branche ist echt komplett im AR... . eigentlich müsste man mal ne entwickler-gewerkschaft gründen und gegen solchen pauschal-globalen dauerschwachsinn streiken und gegen diese klugscheisser-präsenz-kompetenz in anzügen mal angehen.


sorry...bin etwas sauer. heut hat gerade ein neuer sys-admin bei uns angefangen. nen schicken anzug hatte er an und ein 270-Grad-Dauergrinsen. das wars dann aber auch. als er mich dann gefragt hatte was ein DHCP-Server ist war mein tag gelaufen......... :autsch:

 

[robertpic71]

allerdings weiß ich auch nicht so recht was AJAX mit 100%tiger-tastatur-bedienbarkeit zu tun hat ???:L . nem onchange-listener ein submit zu verpassen ging schon lange vor AJAX.

Natürlich war das auch schon vorher möglich. Genau genommen war die Funktionalität (z.B. XMLHttpRequest) von AJAX ja bereits vorhanden, bevor das Schlagwort AJAX überhaupt erfunden wurde. Allerdings hat der AJAX-Hype einiges an Frameworks und neuen Perpektiven für die Webentwicklung gebracht.

Um nocheinmal auf die Tastaturbedienbarkeit zurückzukommen. Die Variante mit Javascript mit Tastaturabfragen, PopUp-Prompter und nachladbaren Comboboxen usw. herumzuschlagen, ist für mich nicht akzeptabel. Ich will fertige Komponenten und mich nicht um Javascript und XMLRequests kümmern müssen. Diese Komponenten gibt es in verschiedenen Frameworks bzw. JSF-Erweiterungen.

Mit dem AJAX-Hype kommen auch Technologien wie Serverpush, die nochmal kräftig an der Web-Einschränkung "zustandlose Verbindung" rütteln.

Keine Frage, jede Webanwendung läßt sich mit Swing wahrscheinlich schöner (Optik/Bedienung) lösen. Aber seine Firmendaten "webfähig" zu machen ist das "Gebot der Stunde". Es ist einfach viel einfacher einem Informationsfluss durch webfähige Anwendungen zu folgen, als z.B. durch gemischte Mainframe und Desktopanwendungen. Eine Webanwendung läßt sich auch viel leichter über das Intranet hinaus zugänglich machen. Wir heißen nicht mehr umsonst EDV- sondern IT-Abteilung.

Ich kann dem AJAX-Hype viel Positives abgewinnen. Ich persönlich finde die Entwicklung mit einem AJAX-Framework überhaupt die leichteste Art, Java-GUI-Programme zu erzeugen. Es verbindet irgendwie die Vorzüge beider Welten (MDA vom Desktop, kein Layoutmanager ;-), EL, einfache Events: onClick=methode....).

sorry...bin etwas sauer. heut hat gerade ein neuer sys-admin bei uns angefangen. nen schicken anzug hatte er an und ein 270-Grad-Dauergrinsen. das wars dann aber auch. als er mich dann gefragt hatte was ein DHCP-Server ist war mein tag gelaufen......... autsch.gif

Die gibts wohl überall.. :bloed:

Noch zu den Chefs: Nur nichts viel wissen, macht noch nichts...aber wenig wissen und glauben das man viel weiß, macht es manchmal mühsam....

/Robert

 

[byte]

AJAX ist auch wieder ao ein komisches "ding". statt generell zu überlegen wie man die viewer (also den browser) um sinnvolle native funktionalitäten und schmale interfaces zu erweitern wird dann so ein ding wie AJAX geboren nur weil sich mal wieder keiner traut den pionier zu spielen.

Native Browsererweiterungen hätten zur Folge, dass das Grundprinzip des Webs übern Haufen geworfen wird. Im Moment basiert das ganze auf Standardtechnologien, die (mehr oder weniger) von allen Browsern (fast) gleich implementiert werden. Native Browsererweiterungen passen da mal überhaupt nicht ins Konzept. Denn dann baut der Entwickler keine Webanwendungen mehr sondern Anwendungen für einen speziellen Browser. Dass das Bullshit ist, hat die Vergangenheit ja schon gezeigt (Stichwort ActiveX Controls).

damit wird sich dann an pseudo-fat-funktionalitäten herangefummelt und einfache seit jahren bekannte funktionalitäten sind das höchste glück des hackers.

Mit Heranfummeln hat das erstmal wenig zu tun, wenn Du fertige Standardkomponenten verwendest. Und ja: das gibts bei FAT Clients schon lange. Aber nun kannst Du sie halt in Webanwendungen verwenden, das heisst niemand braucht ein Programm zu installieren sondern braucht einfach nur einen Browser und Netzzugang.

einmal auf den zurück-button geklickt oder aus versehen auf BSP und ein grossteil aller super-dollen AJAX-anwendungen kommen total durcheinander. design-technisch gehört der ganze web-kram komplett in die tonne.

Offenbar weisst Du nicht, dass es mit Javascript möglich ist, die Funktionalität der Buttons zu manipulieren.

allerdings weiß ich auch nicht so recht was AJAX mit 100%tiger-tastatur-bedienbarkeit zu tun hat ???:L . nem onchange-listener ein submit zu verpassen ging schon lange vor AJAX.

Ich glaube es ging ihm eher um Sachen wie Tastaturkommandos.

nun ja......ich will nicht zynisch sein, aber mit der definition und dem verständnis von AJAX ist's ungefähr so weit her wie mit dem begriff "Web 2.0". jeder benutzt es, aber keiner weiß was es ist.

Du klingst nicht umbedingt zynisch sondern eher verbittert.

mein chef "erkennt" eine AJAX-anwendung z.b. pauschal daran wenn sich irgendwie etwas bewegt. die ganze branche ist echt komplett im AR... . eigentlich müsste man mal ne entwickler-gewerkschaft gründen und gegen solchen pauschal-globalen dauerschwachsinn streiken und gegen diese klugscheisser-präsenz-kompetenz in anzügen mal angehen.

Vielleicht solltest Du mal über einen Wechsel der Firma nachdenken. Bei uns werden technische Entscheidungen immernoch von denjenigen getroffen, die Ahnung von der Materie haben und nicht von irgendwelchen Vertrieblern. Bei Euch scheint das ja ziemlich übel zu sein.
Trotzdem solltest Du Deine Meinung über Webanwendungen mal etwas überdenken und das Ganze etwas objektiver betrachten.

 

[bronks]

... Aber seine Firmendaten "webfähig" zu machen ist das "Gebot der Stunde" ...

Webapps funktionieren eigentlich solange, wie sie funktionieren sollen. Das ganze Desktopzeug, egal ob Java oder etwas anderes, funktioniert eines Tages aus irgendeinem Grund plötzlich nicht mehr oder noch schlimmer: Es funktioniert nicht mehr richtig und mach unerwartet schwere Fehler, welche den gesamten Datenbestand absolut unauffällig ruinieren können, weil neue JRE, weil neue Betriebssystemversion oder weil irgendetwas ein Update erhalten hat.

Web ist für mich der würdige Nachfolger von VT. :toll:

 

[tfa]

Web ist für mich der würdige Nachfolger von VT. :toll:

VT? Videotext? ???:L

 

[ARadauer]

Webapps funktionieren eigentlich solange, wie sie funktionieren sollen. Das ganze Desktopzeug, egal ob Java oder etwas anderes, funktioniert eines Tages aus irgendeinem Grund plötzlich nicht mehr oder noch schlimmer: Es funktioniert nicht mehr richtig und mach unerwartet schwere Fehler, weil neue JRE, weil neue Betriebssystemversion oder weil irgendetwas ein Update erhalten hat.

wobei ich mir sicher bin, dass ein ie update mir meine super fancy webapp leichter zerstören kann, als ein update der jre meine swing app.

 

[bronks]

Web ist für mich der würdige Nachfolger von VT. :toll:

VT? Videotext? ???:L

http://de.wikipedia.org/wiki/VT100

 

[HLX]

statt generell zu überlegen wie man die viewer (also den browser) um sinnvolle native funktionalitäten und schmale interfaces zu erweitern wird dann so ein ding wie AJAX geboren nur weil sich mal wieder keiner traut den pionier zu spielen.

Die Browser-Hersteller (vor allem einer) haben doch heute schon schwierigkeiten vorhandene Standards vernünftig umzusetzen. Wie soll da jemals eine browserunabhängige, allgemeingültige Funktionserweiterung entstehen.

Ich habe bis vor 1-2 Jahre Webanwendungen für bestimmte (tastaturintensive) Anwendungen ausgeschlossen. Aber Dank AJAX ist es jetzt auch möglich 100% tastaturbedienbare Anwendungen für z.B. Telefonverkäufer zu machen.

Die Tastaturbedienbarkeit ist schon wesentlich besser geworden, womit der Kreis der webtauglichen Anwendungen deutlich erweitert wird. Leider kann die Usability von Fat Clients letztendlich nicht erreicht werden. Ich kenne selber 3 Web-Anwendungen, die als Desktop-Derivate daherkommen sollen. Jedes davon hat jedoch seine web-spezifischen Macken. Bei der einen haut einen ein Session-Timeout raus und der soeben eingegeben 50-Zeiler ist weg. Eine andere ist ein Wiki mit WYSIWYG-Editor. Den habe ich 2x benutzt und verzichte nun freiwillig. Dann lieber zu Fuß.

Daher sage ich, dass die Entscheidung Fat-, Smart- oder Thin-Client grundsätzlich eine Frage der Anforderungen an das Produkt und dessen Funktionsumfang ist.

 

[happy_robot]

Mit dem AJAX-Hype kommen auch Technologien wie Serverpush, die nochmal kräftig an der Web-Einschränkung "zustandlose Verbindung" rütteln.

d.h. aber auch daß man sich in zukunft auch in der entwicklung von der zustandslosen darstellung von DB-snapshots in richtung applikation (im sinne eines fat-clients) bewegt. der implementierungs-aufwand wird also auch grösser.

Keine Frage, jede Webanwendung läßt sich mit Swing wahrscheinlich schöner (Optik/Bedienung) lösen. Aber seine Firmendaten "webfähig" zu machen ist das "Gebot der Stunde".

mache ich dir mit jedem fat-client und webstart. gleichzeitig spare ich damit resourcen auf dem server (stichpunkt kosteneinsparung). also was spricht dagegen?

Ich kann dem AJAX-Hype viel Positives abgewinnen. Ich persönlich finde die Entwicklung mit einem AJAX-Framework überhaupt die leichteste Art, Java-GUI-Programme zu erzeugen. Es verbindet irgendwie die Vorzüge beider Welten (MDA vom Desktop, kein Layoutmanager ;-), EL, einfache Events: onClick=methode....).

darüber könnte man sich nun ausgiebig streiten....

Noch zu den Chefs: Nur nichts viel wissen, macht noch nichts...aber wenig wissen und glauben das man viel weiß, macht es manchmal mühsam....

das triffts ziemlich auf den punkt

Denn dann baut der Entwickler keine Webanwendungen mehr sondern Anwendungen für einen speziellen Browser. Dass das Bullshit ist, hat die Vergangenheit ja schon gezeigt (Stichwort ActiveX Controls).

daher sollte man für standardis kämpfen und nicht mit hausgemachten missgeburten wie ActiveX arbeiten.

Aber nun kannst Du sie halt in Webanwendungen verwenden, das heisst niemand braucht ein Programm zu installieren sondern braucht einfach nur einen Browser und Netzzugang.

nun ja....ein browser erfordet sowohl installation als auch einen zugang. er benötigt also genau dieses was du hier als ausschlusskriterium anführst, das ist also dannwohl sicherlich kein argument. es ging mir ja um standardisierte weiterentwicklungen von browsern.

Offenbar weisst Du nicht, dass es mit Javascript möglich ist, die Funktionalität der Buttons zu manipulieren.

weiß ich schon, halte ich aber nicht für eine akzeptable lösung. anwendungen sollten immer noch in sich geschlossen sein und nicht in irgendwelchen containern rumwuseln die sich minütlich ändern können. oder würdest du garantieren daß eine lösung von dir sich exakt auf allen browsern genau so verhält. also ich wäre da vorsichtig.

nun ja......ich will nicht zynisch sein, aber mit der definition und dem verständnis von AJAX ist's ungefähr so weit her wie mit dem begriff "Web 2.0". jeder benutzt es, aber keiner weiß was es ist.

Du klingst nicht umbedingt zynisch sondern eher verbittert.

ja....kann schon sein. jeder der auch nur ein schlagwort hört glaubt alles drumherum zu wissen, weil er sich insgeheim darauf verlassen kann daß seine umgebung es auch nicht gerafft hat. ist das nicht traurig? Letztlich hat bei uns jemand eine Infoveranstaltung über Portalserver gehalten. Nach einer Stunde heisser Luft habe ich mal dumm gefragt was ein Portalserver überhaupt ist. Die Antwort begann mit "Für mich ist ein Portalserver....". Ich bin aufgestanden und gegangen.

Vielleicht solltest Du mal über einen Wechsel der Firma nachdenken. Bei uns werden technische Entscheidungen immernoch von denjenigen getroffen, die Ahnung von der Materie haben und nicht von irgendwelchen Vertrieblern. Bei Euch scheint das ja ziemlich übel zu sein.

das ist sicherlich nicht ungewöhnlich. habe ich fast immer so erlebt. entwickler sind ja generell immer nur sozial-inkompetente volldeppen die sich nur hinterm schirm verstecken und zu doof sind entscheidungen mit gesundem menschenverstand zu fällen.

Trotzdem solltest Du Deine Meinung über Webanwendungen mal etwas überdenken und das Ganze etwas objektiver betrachten.

ich halte sehr viel davon, aber man muss ein gewisses mass halten. ich bin seit drei jahren an meinem eigenen projekt dran und werde wohl bald online gehen. dann schicke ich mal hier links rum. dann wird dir vielleicht klar warum ich das so sehe.

 

[happy_robot]

Die Browser-Hersteller (vor allem einer) haben doch heute schon schwierigkeiten vorhandene Standards vernünftig umzusetzen. Wie soll da jemals eine browserunabhängige, allgemeingültige Funktionserweiterung entstehen.

genau! wäre das nicht grund genug um hier mal kräftig mit neuen zeitgemässen standards und den daraus resultierenden neuen produkten (->neue browsertechnologien) aufzuräumen?
diese überlegung wird vom markt kategorisch ausgeschlossen und stattdessen wieder web-framework entwickelt

 

[byte]

daher sollte man für standardis kämpfen und nicht mit hausgemachten missgeburten wie ActiveX arbeiten.

Erst sprichst du von nativen Browserweiterungen, jetzt auf einmal von offenen Standards? Entscheide Dich mal, was Du willst. Letztere haben wir im übrigen ja.

nun ja....ein browser erfordet sowohl installation als auch einen zugang. er benötigt also genau dieses was du hier als ausschlusskriterium anführst, das ist also dannwohl sicherlich kein argument.

Das ist doch Erbsenzählerei. Auf jedem aktuellen Betriebssystem ist ein Browser drauf. Und Netzzugang braucht ein 2 Tier Fat Client ebenso. Du musst bei der Webanwendung also einfach nur die Seite aufrufen, während Du beim Fat Client die richtige JRE installieren musst und (falls kein Webstart) noch die Anwendung installieren/kopieren.

es ging mir ja um standardisierte weiterentwicklungen von browsern.

Browser setzen nur das um, was die standardisierten Spezifikationen vorgeben. Letztere wurden über die Jahre stetig weiterentwickelt. Was also willst Du genau?

oder würdest du garantieren daß eine lösung von dir sich exakt auf allen browsern genau so verhält. also ich wäre da vorsichtig.

Ja kann ich. Denn das Verhalten ist in den Business Objekten implementiert und liegt auf dem Server. Der Browser stellt das ganze nur dar. Klar siehts nicht auf allen Browsern genau gleich aus, aber das liegt ja nun mal an den Browserherstellern, die sich nicht an exakt an die Standards halten. Die Unterschiede kann man aber mit genügend Know How auf ein Minimum reduzieren.

Im Endeffekt ist die ganze Diskussion eh unsinnig, denn mit geeigneter Architektur ist die Präsentationsschicht eh austauschbar. Ob da nun ein Thin oder Fat Client genutzt wird, ist grundsätzlich wurscht und entscheidet normalerweise eh der Kunde.

jeder der auch nur ein schlagwort hört glaubt alles drumherum zu wissen, weil er sich insgeheim darauf verlassen kann daß seine umgebung es auch nicht gerafft hat. ist das nicht traurig? Letztlich hat bei uns jemand eine Infoveranstaltung über Portalserver gehalten. Nach einer Stunde heisser Luft habe ich mal dumm gefragt was ein Portalserver überhaupt ist. Die Antwort begann mit "Für mich ist ein Portalserver....". Ich bin aufgestanden und gegangen.

Was genau willst Du damit sagen? Weil es Leute gibt, die eine Technologie nicht verstehen, ist diese Technologie schlecht? Du klingst echt verbittert (nich böse gemeint).

das ist sicherlich nicht ungewöhnlich. habe ich fast immer so erlebt. entwickler sind ja generell immer nur sozial-inkompetente volldeppen die sich nur hinterm schirm verstecken und zu doof sind entscheidungen mit gesundem menschenverstand zu fällen.

Jo, da hast Du leider Recht. Als Entwickler ist man meistens nur Betriebsmittel ohne viel Entscheidungsgewalt. Und trotzdem existieren Unternehmen, wo die Entscheidungsträger Fachknowhow haben. So eine würde ich mir suchen, wenn ich Du wäre!

 

[happy_robot]

daher sollte man für standardis kämpfen und nicht mit hausgemachten missgeburten wie ActiveX arbeiten.

Erst sprichst du von nativen Browserweiterungen, jetzt auf einmal von offenen Standards? Entscheide Dich mal, was Du willst.

beides! sollte aber klar sein.

Letztere haben wir im übrigen ja.

naj a....der ist eben nicht mehr zeitgemäss. das ziel das verfolgt wird kann (imho) nur sub-optimal damit umgesetzt werden.

nun ja....ein browser erfordet sowohl installation als auch einen zugang. er benötigt also genau dieses was du hier als ausschlusskriterium anführst, das ist also dannwohl sicherlich kein argument.

Das ist doch Erbsenzählerei. Auf jedem aktuellen Betriebssystem ist ein Browser drauf. Und Netzzugang braucht ein 2 Tier Fat Client ebenso. Du musst bei der Webanwendung also einfach nur die Seite aufrufen, während Du beim Fat Client die richtige JRE installieren musst und (falls kein Webstart) noch die Anwendung installieren/kopieren.
[/quote]
auf jedem aktuellen system ist auch eine JRE drauf. ausser man erliegt einem system daß grundsätzlicxh hauseigene markpolitische interessen verfolgt. selber schuld...

oder würdest du garantieren daß eine lösung von dir sich exakt auf allen browsern genau so verhält. also ich wäre da vorsichtig.

Ja kann ich. Denn das Verhalten ist in den Business Objekten implementiert und liegt auf dem Server. Der Browser stellt das ganze nur dar.

es ging um den für AJAX gefährlichen back-button den du via script ausschalten wolltest. das kannst du eben nicht garantieren, somit kannst du vielles andere auch nicht garantieren und kreigst eventuell zustände an die du nicht mal im schlimmsten traum gedacht hast

Klar siehts nicht auf allen Browsern genau gleich aus

genau diese etwas naive gleichgültigkeit (sorry ) ist der grösste feind eines klaren standards.

Im Endeffekt ist die ganze Diskussion eh unsinnig

trotzdem doch unterhaltsam

denn mit geeigneter Architektur ist die Präsentationsschicht eh austauschbar. Ob da nun ein Thin oder Fat Client genutzt wird, ist grundsätzlich wurscht und entscheidet normalerweise eh der Kunde.

es entscheidet oftmals auch die zur verfügung stehende kompetenz beim auftragnehmer. fat-clients sind doof und schwer und können wir eh nicht. also kriegt der kunde ne web-app......

Was genau willst Du damit sagen? Weil es Leute gibt, die eine Technologie nicht verstehen, ist diese Technologie schlecht? Du klingst echt verbittert (nich böse gemeint).

lol...zeitweise mache ich mir dolle spässe draus probier doch mal selber aus ob die leute die dir etwas erzählen wollen das tatsächlich auch verstanden haben. fundamentale fragen können da schnell zu peinlichen situationen in meetings oder präsentation führen. bei uns haben viele leute aufgehört damit mit kleidsamen akronymen um sich zu schmeissen, da sie genau wissen daß ich nachfrage.

das ist sicherlich nicht ungewöhnlich. habe ich fast immer so erlebt. entwickler sind ja generell immer nur sozial-inkompetente volldeppen die sich nur hinterm schirm verstecken und zu doof sind entscheidungen mit gesundem menschenverstand zu fällen.

Jo, da hast Du leider Recht. Als Entwickler ist man meistens nur Betriebsmittel ohne viel Entscheidungsgewalt. Und trotzdem existieren Unternehmen, wo die Entscheidungsträger Fachknowhow haben. So eine würde ich mir suchen, wenn ich Du wäre!

nöö dann wäre ich ziemlich blöd. ich sitze hier und bastle an meinen eigenen ding (wie gesagt: bin auf dem weg in die selbständigkeit). seit 3 wochen habe ich nicht eine zeile für die firma gehackt.




wie auch immer...
man könnte stundenlang darüber diskutieren ohne zum punkt zu kommen.
mir gehts eigentlich nur darum daß "unsere" branche imho grosse fehler macht. selbstgefälligkeit, inkompetenz, schönfärberei und naive gleichgültigkeit sind doch in der IT-Branche tagwerk. ich bin ja nun auch schon einige jahre dabei und habe schon einige läden gesehen und würde das durchaus jetzt nicht als punktierte persönliche erfahrung werten. der crash 2000 hat doch gezeigt wie man versucht hier geld zu machen. und der fand auch nicht nur in meiner umgebung statt
ich sag' ja auch nicht daß ich besser wäre , aber ich gebe mir mühe mein gegenüber nicht ständig zu verscheissern nur um nicht mein "gesicht zu verlieren". mich kotzt dieses halbwissen-gelaber und selbstgefällige it-business-gehampel einfach an. es fehlen einfach leute die mal auf die bremse treten und mal eine neue saubere richtung vorgeben.

 

[ms]

seit 3 wochen habe ich nicht eine zeile für die firma gehackt.

Ich hoffe für dich, dass das dein Chef nicht liest.

Wir sollten vielleicht dann weiter reden wenn du dein eigenes Projekt fertig gestellt hast und es ans Verkaufen/Vermarkten geht.
Mal sehen ob du dann immer noch so denkst.

ms

 

[happy_robot]

seit 3 wochen habe ich nicht eine zeile für die firma gehackt.

Ich hoffe für dich, dass das dein Chef nicht liest.

er hat kein interesse an IT. warum sollte er das dann hier lesen... er ist ein netter kerl, und sicherlich auch ein guter chef, aber er reiht sich exakt dort ein wo sich viele andere auch platzieren

Wir sollten vielleicht dann weiter reden wenn du dein eigenes Projekt fertig gestellt hast und es ans Verkaufen/Vermarkten geht. Mal sehen ob du dann immer noch so denkst.

verlass dich drauf! bevor ich online gehe lass' ich das hier eh' vielleicht erstmal vom forum checken und bewerten.
mal sehen wie du dann denkst. :lol: