RAD mit RIA und "throwaway screens"?

[openwms.org]

Hallo zusammen,

heute möchte ich einmal ein Thema zum Nachdenken geben, was sicherlich
den ein oder anderen plagt wenn er an seine schönen Webfrontends
vergangener(!) Tage denkt. Ich möchte in diesen Zeit beginnen, als
sich noch alles um Servlets drehte und alles voll und ganz aus HTML
Rendering bestand. Was kam danach? JSP? Weil man das Problem der
Servlets erkannte. Danach? Struts, JSF, ettliche JSF
Komponentenbibliotheken inklusive Ajax Support. Irgendwann sollte man
sich einmal fragen, tut es Not soviel Energie und Zeit in Screens mit
lästigem CSS Layout und JavaScript zu investieren? Diese womöglich
noch mit Firebug zu tracen? Wie oft wird sich die Technologie im
Frontend Bereich noch ändern?

Von daher pflege ich den Begriff der "Thowaway Screens", welchen ich
eigentlich so genial im Zusammenhang mit Web Controllern fand ("Spring
Recipes" von Mak/Apress).

Meiner Meinung nach müsste die Zeit nun vorbei sein, in der man
unnötige Zeit mit dem Layout und dem Studieren von Komponenten
verbacht hat. Als neuestes Baby habe ich AdobeFlex ausprobiert und bin
von diesem Rapid Screen Development völlig begeistert. Die ersten
Gehversuche unternahm ich mit BlazeDS zusammen mit dem gleichnamigen
Spring Subprojekt. Recht früh bin ich dann zu GraniteDS und Cairngorm
umgesiedelt was zusätzliche Vorteile bringt.

Wer also recht fix Webclients erstellen möchte sollte sich dies mal
ankucken, wobei für den Anfang Spring BlazeDS sicherlich eine gute
Unterstützung darstellt.

Grüßle,
</Heiko>

[Manuel Hermann]

Hallo Heiko,

> Meiner Meinung nach müsste die Zeit nun vorbei sein, in der man
> unnötige Zeit mit dem Layout und dem Studieren von Komponenten
> verbacht hat. Als neuestes Baby habe ich AdobeFlex ausprobiert und bin
> von diesem Rapid Screen Development völlig begeistert. Die ersten
> Gehversuche unternahm ich mit BlazeDS zusammen mit dem gleichnamigen
> Spring Subprojekt. Recht früh bin ich dann zu GraniteDS und Cairngorm
> umgesiedelt was zusätzliche Vorteile bringt.

Kannst Du kurz erläutern, warum Du GraniteDS bevorzugst? Wir sind bei einem
Projekt auch gerade dabei eine entsprechende Anwendunsarchitektur auf Basis
von Flex und Spring festzulegen und könnten noch Anpassungen vornehmen.

> Grüßle,
> </Heiko>

Gruß
Manuel

[geramaya]

Ich für meinen Teil halte von den RIA Frameworks recht wenig.
Sie sind alle sehr verschieden und jeder unterstützt die CrossBrowser
Problematik mal gut und mal schlecht.

Aktuell find ich es bedenklich wenn WebApps native Oberfläche nachbauen
mit API und Techniken die sehr komplex sind und keinem Standard entsprechen.
Viele Projekte wählen daher "back to the roots" und nutzen native Anwendungen
oder plattübergreifende (qt, java swing, gtk widgets etc.) Die meisten Argumente
kommen dann mit Auslieferung und Pflege der Applikationen, was nur z.T. richtig
ist - aber hier jetzt nicht das Thema.

Ich nutz gern SpringWebMVC oder Servlet/JSP Basics, da viel Framework draussen
ist und man Basistechnologie hat, die auf Jahre hin Bestand haben kann. Wenn
3-4 XY Frameworks irgendwas auf den Schirm zaubern - halte ich das für größere
Projekte und deren Laufzeiten für bedenklich. Im Geschäftsumfeld sind meistens
Webanwendungen altbacken und kommen mit HTML 3.2 - 4.x mit etwas css daher.
Ajax ist noch lange nicht da, weil sie den Pflegeaufwand solcher Lösungen scheuen.

Alles kommt irgendwann wieder und die Leute besinnen sich wieder öfter mal auf
native Anwendungen auf dem OS. Hm ja .. das ding was man installiert :)

Schauen wir mal was nach der Sommerpause wieder für tolle neue HypeFrameworks
in den Magazinen erscheinen werden.

Kurze Übersicht zu RIAs
http://commadot.com/ria-frameworks/

Greets
Geramaya

[openwms.org]

Hallo Manuel,

also wie erwähnt unternahm ich zuerst einmal den Versuch mit BlazeDS,
welches sich eben mittels Spring gut integrieren lässt. Nun ja, nach
einiger Konfiguration kam ich dann auch in den Genuss meine Spring
Services richtig zu exportieren und als Destination anzusprechen -
ohne zusätzlichen Konfigaufwand in Flex. Mmmh, ich wollte jedoch nicht
auf den gas3 ActionScript VO Generator verzichten. Dies ist ein
praktisches Teilchen, das mittels ANT Task DTOs generiert. Verzichten
muss man darauf ebenfalls nicht wenn man BlazeDS nutzt. Weiterhin
nutzt GraniteDS noch solche Sachen wie Externalizers um Lazy-Loading
zu unterstützen. Letztendlich war für mich auch ausschlaggebend, dass
ich mit GraniteDS nur 1-2 Libraries mehr deployen musste und keine 7
libs. BTW:Google findet viel zu dem Thema BlazeDS vs. GraniteDS.
Granite gabs eben schon als BlazeDS noch kein OSS war und trotzdem hat
es sich bis heute gehalten. Ein change zwischen beiden sollte keine
große Sache sein.

Viele Grüße,
</Heiko>

[openwms.org]

Hallo,

nunja ich wollte mit meinem Post weniger die Diskussion über Pro/
Contra von Fat/Rich/Thin clients anstoßen, bin jedoch über jeden Post
dankbar.
Sicherlich geb ich dir in gewisser Hinsicht auch Recht, mich nervt
eben dieser zunehmend schnelle Wandel in den Frontend Technologien,
daher auch meine
Denkweise: Presentation muss dünn und gut durchschaubar->austauschbar
sein, auch mit SpringMVC und Webflow kann man recht fix Screens
zaubern. Den zusätzlichen Benefit was ich eben bei Flex zur Zeit sehe
ist, dass man mit ziemlich wenig Aufwand und einer guten
Serviceanbindung recht fancy Screens zaubern kann, die sich nebenbei
gut verkaufen lassen :-)

Dass diese rasant wechselnde Technologien natürlich ein Albtraum eines
jedes Supportes sind ist mir natürlich bewusst, daher wenig Logik und
viel Presentation. Probiers einfach aus...

BTW: Ich hab eben einem Kollegen, den ich mit Flex angesteckt habe,
eine Mail beantwortet...Eigentlich soll der gute Knabe eine Oberfläche
mit OpenSwing umsetzen, das hat ihm etwas Bauchschmerzen bereitet,
zumal er sich im Jahre 2009 nicht mehr in Swing einarbeiten wollte.
Seine Meinung war nach einem halben Tag: "...I encounter most of their
component are very rich with lot of things unachieveable by using JSF
or RichFaces (third party JSF)"

Viele Grüße,
</Heiko>

[Manuel Hermann]

Hallo Heiko,

> BTW:Google findet viel zu dem Thema BlazeDS vs. GraniteDS.
> Granite gabs eben schon als BlazeDS noch kein OSS war und trotzdem hat
> es sich bis heute gehalten. Ein change zwischen beiden sollte keine
> große Sache sein.

Danke für die Erläuterungen. Wir haben uns entschlossen erstmal weiter auf
BlazeDS zu bauen. Wir behalten die Entwicklungen aber im Auge.

Gruß
Manuel

[Manuel Hermann]

> Denkweise: Presentation muss dünn und gut durchschaubar->austauschbar
> sein, auch mit SpringMVC und Webflow kann man recht fix Screens
> zaubern. Den zusätzlichen Benefit was ich eben bei Flex zur Zeit sehe
> ist, dass man mit ziemlich wenig Aufwand und einer guten
> Serviceanbindung recht fancy Screens zaubern kann, die sich nebenbei
> gut verkaufen lassen :-)

Das ist eigentlich das Hauptargument. Ich würde es moderne und ansprechende
Anwendungsoberflächen nennen. Die besagten altbackenen HMTL-Masken sind zwar
aktuelle Realität, aber oft nicht unbedingt vom Kunden gewünscht, wenn er
die Wahl hätte.

Gruß
Manuel