Ruby on Rails

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/ruby_on_rails_143983/page_1 - zur Vollversion wechseln!

funka schrieb am 11.06.2005 um 19:24

Jeder der sich momentan mit Webdevelopment (mehr oder weniger) beschäftigt sollte sich definitiv Ruby on Rails ansehen.

Vorallem der AJAX (async. javascript and xml) support (via "Prototype") ist abartig simpel. [3]

intros:
[1] http://www.onlamp.com/pub/a/onlamp/...1/20/rails.html
[2] http://www.onlamp.com/pub/a/onlamp/...3/03/rails.html

[3] http://www.onlamp.com/pub/a/onlamp/...rails_ajax.html



Offizielle Homepage: http://www.rubyonrails.org/

gue schrieb am 11.06.2005 um 19:49

Hmmm das Demo hier: http://blog.curthibbs.us/articles/2...1/ajax-on-rails funzt bei mir mit Opera 8 nicht :/
Und was machen Personen, deren Browser kein JavaScript unterstützt/deaktiviert ist? :/

COLOSSUS schrieb am 11.06.2005 um 19:53

Ruby rockt allgemein sehr stark. Hoffentlich wird es sich in naher Zukunft staerker verbreiten :)

Rektal schrieb am 11.06.2005 um 22:41

Die Minimierung der Roundtrips zum Server sind definitiv auf dem Vormarsch. Idialerweise gibts fuer Browser ohne JS immer ein Fallback, was aber nicht in allen Umgebungen noetig ist. Den richtigen Mehrwert seh' ich eher in Backend-Applikationen die immer einen eingeschraenkten Benutzerkreis (Admins, Redakteure, whatever) haben, deren Browseranforderungen definierbar sind.

Ich finde nur, dass der Trend, HTML fuer immer mehr GUI Applikationen zu verwenden, lieb & nett ist, aber oft, vor allem X-Browser Kompatibilitaet, der Aufwand, das noetige QA und die Elemente neu Erfinden weil sie nicht existieren, irgendwie unwirtschaftlich ist. IMHO. Multiple file selection? Gibts nicht. Nur mit ActiveX IE oder FF Extension. Combobox? Ohne Neuentwicklung in JS nicht vorhanden, selbst dann ist die Useability mit echten Comboboxen schwer zu erreichen, dann wieder das X-Browser Problem. Slider Balken? Oja, Safari als proprieaeteres Tag, andere Browser nicht, maximal FF mit XBL, wieder ein ActiveX fuer IE hmm. Oder einfach nur scrollable listen, trees? Aehem. Die meisten Anforderungen erfuellt XUL, doch auch hier ist die Entwicklung so rasend, die Dokumentation teils beduerftig und schnell wieder inaktuell.

Dann kommt dazu, dass (vor allem IE), bei intensiverer Manipulierung des DOMs ziemlich ins schludern kommt. Man bekommt dann noch mehr das Gefuehl, Beta-Tester zu sein :-(

Ich bekomme das Gefuehl das im Jahr '05 keine fertigen, ausgereiften Werkzeuge fuer Webentwickler existeren, die ansprechend UI Elemente bieten, um die einfachsten Dinge zu bewerkstelligen, die fuer normale User eigentlich selbstverstaendlich sind. Im kommerziellen Bereich sicher moeglich .. aber ... :)

X3ll schrieb am 12.06.2005 um 13:29

Gibts da auch ein Einstiegs Tutorial auf Deutsch ?

Troy schrieb am 12.06.2005 um 14:59

auf deutsch bisweilen nichts gefunden, aber diese hier sind recht einfach
http://poignantguide.net/ruby/
http://www.whytheluckystiff.net/ruby/pickaxe/

funka schrieb am 12.06.2005 um 15:30

Zitat von Rektal
Ich bekomme das Gefuehl das im Jahr '05 keine fertigen, ausgereiften Werkzeuge fuer Webentwickler existeren, die ansprechend UI Elemente bieten, um die einfachsten Dinge zu bewerkstelligen, die fuer normale User eigentlich selbstverstaendlich sind. Im kommerziellen Bereich sicher moeglich .. aber ... :)
ja absolut korrekt
aber es geht bei dem was sich jetzt hip ajax nennt auch mehr meistens um die verbesserung vorhandener interfaces - und weniger um die generierung neuer

ich finds extrem interessant wie simpel man mit rubyonrails prototypes erstellen kann - ich mein allein die integration von datenbanken ist einfach nur plain and simple straight forward

es ist klar das in jedem it bereich hypes kommen und gehen und es geht auch nicht darum dass jetzt alles stehen und liegen gelassen wird und wir pilgern gehen - es ist einfach interessant zu sehen wie schnell die latte im webdev bereich '05 hoeher gelegt wurde
gmail, google suggest, google maps und jetzt mit frameworks wie rails kann mans sogar selbst (SEHR SIMPEL - darum gehts mir) machen

rails ist ja am anfang des jahres erst public geworden
ich bin gespannt wie schnell sich dass auf andere dev umgebungen auswirkt - ob es ein python on rails auch geben wird? waer sehr sexy - zope ist leider nicht so sexy wie ichs mir erwartet hab

watchout schrieb am 14.06.2005 um 14:36

Ich weiss nicht, bin der Meinung man sollte ohne viel JS schnickschnack auskommen... Obwohl ich bis jetzt leider kaum Zeit gefunden hab mich ins Ruby on Rails einzulesen.

derelict schrieb am 15.06.2005 um 10:24

Frameworks are bad.

Ein Framework ist für einen bestimmten Zweck designed, und solange man in diesem Definierten Rahmen bleibt, ist die Nutzung produktiv.

Verlässt man diesen Rahmen aber (und das ist bei jeder ernsthaften Applikation der Fall), dann wird die Sache unübersichtlich, umständlich und kostet am Ende mehr Zeit als ohne Framework.

Bei Rails ist dieser Ansatz extrem - Es ist schon fast alles vorgegeben, Transparenz kaum vorhanden.
Ajax: nix neues unter einem neuen Namen und es hyped. Die Anwendungsfälle sind eingeschränkt dadurch dass zwecks kompatibilität noch immer roundtrips möglich sein müssen.

mat schrieb am 15.06.2005 um 11:39

Zitat
Verlässt man diesen Rahmen aber (und das ist bei jeder ernsthaften Applikation der Fall), dann wird die Sache unübersichtlich, umständlich und kostet am Ende mehr Zeit als ohne Framework.
ich kenne rails nicht, allerdings gibt es genügend objektorientierte wege die ein "verlassen des frameworks" problemlos und übersichtlich ermöglichen. ich behaupte mal das ruby, als smalltalk ähnliche sprache, das ohne weiteres kann.

eine ernsthafte applikation sollte ebenfalls niemals ohne framework auskommen müssen. ein framework gibt eine architektur vor, ein dokumentiertes grundgerüst. alles was diesen rahmen verlässt sollte es gekonnt verlassen.. meist ebenfalls in einem vordefinierten rahmen, meist einem design pattern.

"frameworks are bad" ist imo eine falsche aussage.. frameworks sind sehr schwierig zu schreiben, weil sie in ihrer definition keinen bestimmten anwendungszweck haben. das ein schlecht geschriebenes oder schlecht dokumentiertes framework kontraproduktiv ist, ist imo genauso klar wie die tatsache das (größere) anwendungen ohne einheitlicher architektur schwer zu warten, erlernen, usw. sind.

derelict schrieb am 15.06.2005 um 15:17

Klar kannst du das Framework "verlassen", nur wird es eben an diesem Punkt unübersichtlich.
Zur Definition: Ein Framework ist für mich ein Scope in dem meine Applikation laufen muss. Sobald dieser Scope zu eingeschränkt ist, oder man 2 Frameworks verwenden will ... uff ;)

Da halte ich vom Utility-Ansatz (Applikation verwendet funktionalitäten) mehr.

Dass die Begriffe öfters vermischt werden, ist mir bewusst.

edit: genau da bin ich anderer meinung: ein Framework muss eine bestimmte Aufgabe erfüllen ... und ich denke genau da liegt der Grund warum die meisten unbrauchbar sind - die anforderung liegt bei "soll alles vereinfachen", und das ist nunmal etwas unrealistisch.

mat schrieb am 15.06.2005 um 15:32

nein, ich hab gesagt, dass man ein framework gekonnt verlassen.. vorausgesetzt es ist gut strukturiert und man beherrscht es ;)

2 unterschiedliche frameworks können für mich nur in 2 applikationen gesteckt werden.. alles andere ist für mich ein fehler in der konzeptionierungsphase.

unterhalb eines frameworks befindet sich bei mir der "Library-Ansatz" :p, das sind libraries für einen speziellen gebrauch (zB ZLib, jpeg, usw.) die (ich) gerne in das framework verstaut werden.

btw: es gibt eine sehr gute begriffserklärung inklusiver vieler tipps in Gammas "Design Patterns" (http://www.amazon.com/exec/obidos/t...5066971-2303802)

derelict schrieb am 15.06.2005 um 16:00

Weil du Design Patterns ansprichst: genau dort sehe ich den Knackpunkt: Das Framework implementiert den einen oder anderen Design Pattern, trifft für dich Annahmen was dein Design angeht.
Brauchst du jetzt eine abweichende Implementierung, müsste dir das Framework die entsprechenden Schnittstellen liefern. Dass es das nicht 100%ig kann, versteht sich von selbst. Zumindest habe ich noch kein Framework benutzen dürfen, an dessen Grenzen ich nicht gestoßen bin, und dann viel Zeit verschwenden musste, das vorgehabte im Rahmen des Frameworks umständlich umzusetzen. Vermutlich verstehen wir aber auch etwas anderes unter "verlassen".

Am beispiel des MVC-Patterns: Framework X implementiert dir Controller und Stellt dir ein Templatesystem für deine View zur Verfügung. Bei deinem Model lässt es dir alle Freiheiten. Sobald du jetzt z.B. ein abweichendes Verhalten im Controller brauchst, bist du auf programmatische schnittstellen oder configurationsoptionen des Frameworks angewiesen. Allein dadurch reduziert sich die Brauchbarkeit von Frameworks für größere Apps schnell gegen 0, weil du es nicht mehr schaffst deine gesamte App im Rahmen des Frameworks zu entwickeln, was wiederum die Homogenität und damit die Wartbarkeit negativ beeinflusst.
Und im Grunde wolltest du garnicht aus dem Framework "aussteigen" - weil du die von ihm gebotenen Features weiter nutzen willst, sondern lediglich Funktion X anders haben.

Von ins Framework verwursteten Libs halte ich noch weniger. Wenn ich eine Framework-Abstraction brauche, ist die Lib schlecht, von mir aus ein Wrapper für die Lib, aber nicht integriert, da hast du wieder das Problem wenn du eine andere Lib verwenden willst.

cypher schrieb am 15.06.2005 um 20:27

Zitat von creAlict
Weil du Design Patterns ansprichst: genau dort sehe ich den Knackpunkt: Das Framework implementiert den einen oder anderen Design Pattern, trifft für dich Annahmen was dein Design angeht.

Ja. Ist das nicht der Sinn eines Frameworks, gewisse Funktionalitaet bereit zu stellen die (hoffentlich) einem gewissen Design folgt?

Zitat
Brauchst du jetzt eine abweichende Implementierung, müsste dir das Framework die entsprechenden Schnittstellen liefern. Dass es das nicht 100%ig kann, versteht sich von selbst. Zumindest habe ich noch kein Framework benutzen dürfen, an dessen Grenzen ich nicht gestoßen bin, und dann viel Zeit verschwenden musste, das vorgehabte im Rahmen des Frameworks umständlich umzusetzen. Vermutlich verstehen wir aber auch etwas anderes unter "verlassen".

Naja, es heisst ja net umsonst "Framework" (wortwoertlich Rahmenwerk). Wenn es nicht diesen Rahmen fuer deine App zur Verfuegung stellen wuerde, waere es ja "nur" eine Library. Und manche Frameworks sind restriktiver als andere. Mit RoR hab ich hinsichtlich Freiheit eigentlich nur gute Erfahrungen gemacht. RoR kuemmert sich an sich ja nur um die Drecksarbeit im Hintergrund und liefert z.b. wenn notwendig fertige Views fuer Datensaetze, wenn diese noch nicht vom Entwicklerteam implementiert wurden. Aber sobald diese implementiert wurden, laesst Rails seine Finger davon. Zusaetzlich hatt man auch viele Helper Functions, die einem das Leben doch sehr erleichtern.

Zitat
Am beispiel des MVC-Patterns: Framework X implementiert dir Controller und Stellt dir ein Templatesystem für deine View zur Verfügung. Bei deinem Model lässt es dir alle Freiheiten. Sobald du jetzt z.B. ein abweichendes Verhalten im Controller brauchst, bist du auf programmatische schnittstellen oder configurationsoptionen des Frameworks angewiesen. Allein dadurch reduziert sich die Brauchbarkeit von Frameworks für größere Apps schnell gegen 0, weil du es nicht mehr schaffst deine gesamte App im Rahmen des Frameworks zu entwickeln, was wiederum die Homogenität und damit die Wartbarkeit negativ beeinflusst.
Und im Grunde wolltest du garnicht aus dem Framework "aussteigen" - weil du die von ihm gebotenen Features weiter nutzen willst, sondern lediglich Funktion X anders haben.

Wie ich bereits oben erwaehnte ist das IMO in RoR sehr gut geloest worden. Ich muss allerdings auch zugeben dass ich dazu keine wirklich objektive Meinung abliefern kann ;)

/me <= Ruby-Suchtler

mfg, cypher

mat schrieb am 18.06.2005 um 02:47

Zitat
Weil du Design Patterns ansprichst: genau dort sehe ich den Knackpunkt: Das Framework implementiert den einen oder anderen Design Pattern, trifft für dich Annahmen was dein Design angeht.
Brauchst du jetzt eine abweichende Implementierung, müsste dir das Framework die entsprechenden Schnittstellen liefern. Dass es das nicht 100%ig kann, versteht sich von selbst. Zumindest habe ich noch kein Framework benutzen dürfen, an dessen Grenzen ich nicht gestoßen bin, und dann viel Zeit verschwenden musste, das vorgehabte im Rahmen des Frameworks umständlich umzusetzen. Vermutlich verstehen wir aber auch etwas anderes unter "verlassen".
da ich atm mehr am framework schreiben bin, als am benutzen kann ich nur sagen, dass man gerade bei webentwicklung selten an designgrenzen stößt. jegliche grenzen die ich während der entwicklung mitbekam, spielten sich im templatebereich ab, und das nur deshalb weil javascript browserindependent miteinbezogen wurde.
Zitat
Am beispiel des MVC-Patterns: Framework X implementiert dir Controller und Stellt dir ein Templatesystem für deine View zur Verfügung. Bei deinem Model lässt es dir alle Freiheiten. Sobald du jetzt z.B. ein abweichendes Verhalten im Controller brauchst, bist du auf programmatische schnittstellen oder configurationsoptionen des Frameworks angewiesen. Allein dadurch reduziert sich die Brauchbarkeit von Frameworks für größere Apps schnell gegen 0, weil du es nicht mehr schaffst deine gesamte App im Rahmen des Frameworks zu entwickeln, was wiederum die Homogenität und damit die Wartbarkeit negativ beeinflusst.
Und im Grunde wolltest du garnicht aus dem Framework "aussteigen" - weil du die von ihm gebotenen Features weiter nutzen willst, sondern lediglich Funktion X anders haben.
wäre kein problem, würde der controller (ordentlich dokumentiert) jegliche objekt-orientierten möglichkeiten zulassen. erweiterung eines frameworks darf _niemals_ problematisch sein.
Zitat
Von ins Framework verwursteten Libs halte ich noch weniger. Wenn ich eine Framework-Abstraction brauche, ist die Lib schlecht, von mir aus ein Wrapper für die Lib, aber nicht integriert, da hast du wieder das Problem wenn du eine andere Lib verwenden willst.
wrapper = ins framework integrierte libs :)



overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025