Das kann man sicher machen, ist aber eine Entscheidung von
beträchtlicher Trageweite. Im wesentlichen gibt es dann nur noch
jeweils einen GET-Request, um das Gerüst der Seite aufzubauen, von da
an agieren die Skripte wie eine Client-Anwendung, die die Controller
als Webservice nutzt.
Kann man alles mit Prototype machen; evtl. unterstützt durch LowPro,
Jester und JavaScript Routes (o.ä.).
nee, klar, sicher, machen kann man ja immer vieles: Nur, ist es eine
gute Idee? Werden bald alle Anwendungen so aussehen (Return of the
Evil Client-Server-Architecture)? Von da aus ist der Weg dann
leichter, statt prototype/scriptaculous einfach gwt zu nehmen. oder
flex. oder was auch immer.
Hat aber mit meiner ursprünglichen Frage nicht mehr viel zu tun.
hmm. ja. Aber wenn die Frage war, ist es sinnvoll, weiter bei P+S zu
bleiben, dann macht es Sinn, vorher drüber nachzudenken, wie tief sich
prototype in die Anwendung eingegraben hat. und einen Moment an die
Überlegung zu verschwenden, wohin einen rails mit rjs geführt hat.
Alle rjs-basierten Sachen und die ganzen remote-helper binden die
Anwendung an prototype, da würd ich dann immer dreimal überlegen, ob
man noch was dazu tut . Während es mit diesem Head-Pattern sicher
leichter fällt, zu anderen Frameworks zu wechseln.
Sorry, wollte deinen Thread nicht hijacken, aber ich suche momentan
nach einer auch architektonisch sauberen Lösung, andere Frameworks zu
benutzen - die rails-Bordmittel mit anderen Frameworks zu mixen hat
bei uns nur zu einem wenig glücklichen Mischmasch aus
handgebautem&generiertem Code geführt.: Das wäre dann die Frage vor
der Frage: Wenn andere Frameworks, wie baut ihr die ein? Wie ko-
existieren die mit p+s? Benutzt ihr das zusammen oder die eingebauten
Sachen dann gar nicht mehr?
Grüße
stefan
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
