Hallo Thorsten,
was Du erzählst deckt sich eingentlich ziemlich genau mit meinen
Erfahrungen: exzessiver Einsatz von rjs führt in der Regel zu ziemlich
zerfleddertem Code. Keine Ahnung, ob man mehr (sehr viel
mehr...)Disziplin das auch in größeren Anwendungen sauber halten kann,
aber wenn man mehr Interaktion im Client hat, dann gibt es immer
irgendjemanden, der per js auf generierte ids zugreift, partials, die
zu viel tun, actions die extrem spezialisiert für einen ajax-call
irgendwas zusammen bauen usw. Ich bin immer noch der Meinung, dass das
weniger an uns liegt, als vielmehr an rjs - das taugt für eine
schnelle Demo, aber wenn's größer wird, dann ist es kaum zu vermeiden,
dass es unübersichtlich wird.
Wir haben da irgendwann mal den Stecker gezogen und setzen seither rjs
entweder nur noch sporadisch für Prototypen oder sehr isoliert an den
Stellen ein, wo wir nur sehr wenig und dann sehr standardisiertes AJAX
brauchen. Größere Sachen machen wir eigentlich in der Regel mit ext
und frei nach Ajax-Head-Pattern (z.B.: http://www.metaskills.net/2008/5/24/the-ajax-head-br-design-pattern)
- ob man da jetzt ext oder dojo oder jquery oder sogar sproutcore/
cappucino/gwt nimmt, spielt dabei eigentlich keine Rolle: Wichtig
scheint mir dabei der Trend zu sein, deutlich mehr Funktionalität in
den javascript-Client zu schieben und die Server-Seite dabei deutlich
zu entrümpeln.
Bei uns hat das zu einer deutlicheren Trennung der Schichten und
loseren Kopplung geführt: Meistens kann man sich auf dem Server auf
sehr einfache(=besser wiederverwendbare) Controller beschränken), die
entweder per json oder xml die Daten zum Client hinpumpen, der dann
irgendwas damit macht und sie dann wieder zurückschreibt. Der Server
sagt eigentlich nichts mehr außer OK oder ERROR und jeder beschränkt
sich darauf, was er am Besten kann, keine Vermischung mehr, bessere
Testfähigkeit (weil weniger Kopplung), keine obskuren Code-
Generierungsprobleme und man kann damit dann auch wieder leichter
andere Clients (eine iphone-app, eine flex/air-client) usw. an die
Controller anschließen, weil eben kein rjs mehr rausgeworfen wird, mit
dem niemand was anfangen kann...
Nachteil der Geschichte ist, dass man mehr Zeit im Client mit
javascript verbringt, und nicht von Rails davor bewahrt wird, selber
javascript zu schreiben: Die Lernkurven für beinah jedes dieser
Frameworks sind schon recht steil, die API's zum Teil kryptisch und
gewöhnungsbedürftig und mittlerweile auch einfach umfangreich -
irgendwie war's auch schön einfach, alles aus einer Hand zu bekommen...
Vielleicht ist das kein Pattern für alles, aber bei uns hat's an
einigen Stellen geholfen, den Wildwuchs deutlich zurecht zu schneiden...
Viele Grüße
Stefan
Am 15.02.2009 um 11:01 schrieb Thorsten Schmidt:
Hallo,
derzeit stehe ich vor der Situation, eine Rails 1.2 Anwendung auf
2.2 zu
portieren. Die Ursprungsanwendung ist überhaupt nicht restful; zudem
ist
JavaScript an vielen Ecken notwendig (soll auch so bleiben).
Nun wollte ich kurz in die Runde werfen, welche Designkriterien dazu
passen. Bislang sieht das ganze so aus:
A1) Wir nutzen Prototype-Helper aus Rails wo immer möglich
A2) Wir nutzen JSON nicht
A3) Jede Ajax-Action rendert ein .rjs template, dass eine Einsetzung /
Anpassung der View vornimmt.
A4) Keine Ajax-Action führt Änderungen in der Datenbank aus.
A5) Zur Verarbeitung der Ajax-Routinen, gibt es Funktionen in der
application.js, die von den .rjs Templates aufgerufen werden.
z.B.
- Object O steht in einer belongs_to Relation B.
- Via Ajax kann der Benutzer im Formular zu O ein passendes B suchen
- o
der er gibt an, dass er ein neues B erstellen will.
- Die Wahl wird im Formular zu B vermerkt und bei der Verarbeitungs
des
Submits angewendet.
Dies bringt einige Probleme mit sich:
P1) Code ist ziemlich "zerhakt". Es gibt ein labiles Zusammenspiel aus
partials, .rjs und application.js. Automatisiertes Refactoring ist
praktisch nicht möglich
P2) Die Controller sind durchzogen von AutoComplete, etc. Actions und
werden unübersichtlich
Welche Überlegungen sollte ich jetzt beim Refactoring Anwenden?
- Gibt es Gute Alternativen zu A3)?
- Ist es realistisch nach dem Grundsatz: "JavaScript-Code (der nicht
von
prototype-Helpern generiert wird), darf keine Attributnamen enthalten"
zu verfahren?
Danke,
Bis Dene
Thorsten
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/listinfo/rubyonrails-ug
----
stefan frank
vierundsechzig.de
software&service
weberstr. 10
69120 heidelberg
tel. +49 (0) 6221 7277049
mobil +40 (0) 173 2383390
mail [email protected]
www.vierundsechzig.de
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/listinfo/rubyonrails-ug
