On Saturday 02 June 2007, Stefan Tilkov wrote: > On Jun 2, 2007, at 1:44 AM, Michael Schuerig wrote: > > On Friday 01 June 2007, Stefan Tilkov wrote:
> >> Wie strukturierst Du Deine Anwendung? Funktioniert sie auch, wenn > >> JavaScript deaktiviert ist? Wenn ja, lässt sich die RJS-Variante > >> als eine andere Repräsentation der Ressource sehen, die Du im > >> Nicht-JS- Fall verwendest? > > > > Nein, ohne JS läuft da gar nichts. Da es sich um eine interne > > Anwendung > > handelt ist das so auch in Ordnung. Öffentlich würde ich das anders > > angehen. > > Hm, vielleicht ist es dann einfach OK, das ganze nicht RESTful zu > realisieren. Ich würde behaupten, dass die Vorteile (wie z.B. > "Bookmarkability") auch für interne Anwendungen gelten, aber das ist > letztlich eine Designentscheidung. Oh, das ist ein Missverständnis. Die Anwendung ist vollständig bookmarkable. Was nicht geht, das ist, eine Bookmark auf den Zustand eines halb ausgefülltes Formular zu setzen. > Wenn Du es aber RESTful realisieren würdest, hast Du ja eigentlich > nur deswegen ein Problem, weil Du RJS auf dem Server machst - > richtig? Das konzeptionelle Modell wird sozusagen "verletzt", weil > durch RJS Logik, die eigentlich in den Client gehört, im Server > sitzt. Oder anders gesagt: würdest Du plain Javascript in Deine HTML- > Seite einbetten, könntest Du mit Ressourcen auf dem Server agieren, > ohne einen Seitenwechsel zu provozieren. Einen Seitenwechsel gibt es auch mit RJS nicht. Aber, um die Idee weiter zu spinnen, ich könnte Jester (http://giantrobots.thoughtbot.com/2007/4/2/jester-javascriptian-rest) nehmen und auf dieser Grundlage den Client komplett in JavaScript schreiben. Das will ich aber nicht, weil es, glaube ich, der Anwendung nicht gerecht würde. Es wäre auch mehr Arbeit, weil ich keine vergleichbaren Hilfsmittel hätte, wie sie in Rails für eine "klassische" Anwendung verfügbar sind. Eigentlich möchte ich das genaue Gegenteil. Mein Client soll zwar nicht unbedingt dumm sein, er soll aber unspezialisiert sein. Der Client-Code soll möglichst unabhängig von der Geschäftslogik sein. Das ist in meiner Konfigurationsanwendung derzeit nur zu ~80% gegeben, da habe ich einigen anwendungsspezifischen Code im Client, der bei (allerdings gravierenden) Änderungen der Geschäftslogik angepasst werden müsste. Ich schreibe zwar überraschend gerne JavaScript-Code, aber das ist unter dem Gesichtspunkt Lokalisierung von Belangen unschön. [Polling, um "schale" (stale) Objekte zu erkennen] > Cool :-) Aber im Prinzip gilt das gleiche - die Funktionalität, eine > Ressource zu fragen, ob sie sich seit dem letzten Zugriff geändert > hat, ist in HTTP schon drin (ETags/Last-modified header usw.) Wenn Du > darauf aus dem Client zugreifen würdest, wäre alles in Butter ... > Edge Rails macht auch schon ETags, das könnte man mit einer Lösung > kombinieren, die Deinen Use Case generisch löst ... nettes Spielfeld. Stimmt, ich löse etwas auf Anwendungsebene, was in HTTP prinzipiell schon vorhanden ist. Ich könnte im Etag-Header die aktuelle Versionsnummer des "Hauptobjekts" verschicken. Ein HEAD-Request geht wohl auch per XHR. Was mir nicht gefällt ist das Thema Internationalisierung. Wenn das bearbeitete Objekt nicht mehr aktuell ist, soll der Client dies dem Benutzer mitteilen. Bisher halte ich es so, dass alle Texte serverseitig erzeugt werden. Sie stehen in Views oder Rails-Code -- in diesem Fall RJS --, wo sie bei Bedarf relativ problemlos mit Hilfe verschiedener Plugins lokalisiert werden könnten. Wenn ich mich obendrein noch um Lokalisierung in JavaScript kümmern muss, dann habe ich einen Bruch in der Anwendung wie auch in der Werkzeugunterstützung. Natürlich geht I18N auch in JS, indem die ortsabhängigen Teile in individuelle Skripte ausgelagert werden, die dann bedarfsweise aus der Seite verlinkt werden. Es ist aber mühsamer. > Je länger ich darüber nachdenke, um so mehr komme ich zu der Meinung, > dass das nicht zusammenzubringen ist - der Server müsste reine Daten, > nicht Code liefern, wenn das (an dieser Stelle) RESTful sein soll. Ja, das denke ich auch. Interessant wird es aber dadurch, dass ich den Client zwar, wie gesagt, durchaus intelligent haben möchte, er aber möglichst wenig von der Geschäftslogik wissen soll. Man kann in JavaScript beeindruckend schönen Code schreiben http://www.adamlogic.com/2007/03/20/3_metaprogramming-javascript-presentation Aber *das* ist genau der Code, den ich nach Möglichkeit niemals schreiben möchte. Schönen Code nehme ich natürlich gerne. Ideal wäre es aber, wenn per Reflection eine deklarative Repräsentation von relevanten Constraints der Geschäftslogik erzeugt werden könnte (buzz buzz buzz). Der Client muss wissen, bei welchem Ereignis er dem Server welche Frage stellen und was er mit dem Ergebnis machen soll. Zum Vergleich, die clientseitige Validierung von Formulareingaben passiert bereits automatisch auf der Grundlage der Validations, die in den Model-Klassen definiert sind. http://schuerig.de/michael/blog/index.php/2006/12/15/rails-almost-automatic-client-side-validation/ > > Ich habe, sinngemäß > > > > http://example.com/cars/update_ui/7?model=X&variant=Y&;... > > > > was einen RJS-generierten Mischmasch aus Funktionsaufrufen und > > HTML-Fragmenten liefert, die irgendwie das richtige tun. > > > > Resource-oriented könnte ich eine ganze Reihe von "algorithmischen" > > (berechneten, parametrisierten) Ressourcen definieren > > > > http://example.com/cars/available_motors?model=X&variant=Y&;... > > http://example.com/cars/available_colors?model=X&variant=Y&;... > > ... > > > > die zweifellos allgemeiner wären. > > Ja, und auch im Sinne eines Web Services verwendbar ... > > > Mir aber clientseitig viel mehr Mühe > > bereiten würden: mehrere Ajax-Requests statt nur eines einzelnen. > > Warum mehr Requests? Weil dann der Matsch, den ich derzeit auf einen einzelnen "RPC"-Request hin zurück liefere, sauber auf mehrere Ressourcen aufgeteilt ist. > Trotzdem danke ... ich habe zwar schon viel mit REST, aber extrem > wenig mit Ajax gemacht und finde das deswegen eine sehr interessante > Diskussion. Falls Du Mo/Di zufällig bei den holländischen Suppenkaspern im Schatten der zwei Türme bist, könnten wir auch IRL weiter diskutieren. :-) Wenn noch jemand ausser Stefan bis hier durchgehalten hat: Ja, das sollte kryptisch sein. Michael -- Michael Schuerig mailto:[EMAIL PROTECTED] http://www.schuerig.de/michael/ _______________________________________________ rubyonrails-ug mailing list [email protected] http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
