Ruby on Rails

funka

Legend
ex-prophet(down below)

Registered: Sep 2000
Location: Vienna / SF
Posts: 6131

11.06.2005 - 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

Addicted

Registered: Feb 2003
Location: Linz
Posts: 400

11.06.2005 - 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

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12070

11.06.2005 - 19:53

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

Rektal

Here to stay

Registered: Dec 2002
Location: Inside
Posts: 4452

11.06.2005 - 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

╰(*°▽°*)╯

Registered: Mar 2002
Location: /dev/null
Posts: 1243

12.06.2005 - 13:29

Gibts da auch ein Einstiegs Tutorial auf Deutsch ?

Troy

amateur

Registered: Feb 2002
Location: Wien
Posts: 4393

12.06.2005 - 14:59

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

funka

Legend
ex-prophet(down below)

Registered: Sep 2000
Location: Vienna / SF
Posts: 6131

12.06.2005 - 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

Legend
undead

Registered: Nov 2000
Location: Off the grid.
Posts: 6845

14.06.2005 - 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

Legend
Legend

Registered: May 2004
Location: outside
Posts: 365

15.06.2005 - 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

Administrator
Legends never die

Registered: Aug 2003
Location: nö
Posts: 25422

15.06.2005 - 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

Legend
Legend

Registered: May 2004
Location: outside
Posts: 365

15.06.2005 - 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

Administrator
Legends never die

Registered: Aug 2003
Location: nö
Posts: 25422

15.06.2005 - 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"

, 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

Legend
Legend

Registered: May 2004
Location: outside
Posts: 365

15.06.2005 - 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

Bloody Newbie

Registered: Feb 2005
Location: FH Hagenberg
Posts: 12

15.06.2005 - 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

Administrator
Legends never die

Registered: Aug 2003
Location: nö
Posts: 25422

18.06.2005 - 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

funka Legend ex-prophet(down below) Registered: Sep 2000 Location: Vienna / SF Posts: 6131	11.06.2005 - 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 Addicted Registered: Feb 2003 Location: Linz Posts: 400	11.06.2005 - 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 Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12070	11.06.2005 - 19:53 Ruby rockt allgemein sehr stark. Hoffentlich wird es sich in naher Zukunft staerker verbreiten
Rektal Here to stay Registered: Dec 2002 Location: Inside Posts: 4452	11.06.2005 - 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 ╰(°▽°)╯ Registered: Mar 2002 Location: /dev/null Posts: 1243	12.06.2005 - 13:29 Gibts da auch ein Einstiegs Tutorial auf Deutsch ?
Troy amateur Registered: Feb 2002 Location: Wien Posts: 4393	12.06.2005 - 14:59 auf deutsch bisweilen nichts gefunden, aber diese hier sind recht einfach http://poignantguide.net/ruby/ http://www.whytheluckystiff.net/ruby/pickaxe/
funka Legend ex-prophet(down below) Registered: Sep 2000 Location: Vienna / SF Posts: 6131	12.06.2005 - 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 Legend undead Registered: Nov 2000 Location: Off the grid. Posts: 6845	14.06.2005 - 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 Legend Legend Registered: May 2004 Location: outside Posts: 365	15.06.2005 - 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 Administrator Legends never die Registered: Aug 2003 Location: nö Posts: 25422	15.06.2005 - 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 Legend Legend Registered: May 2004 Location: outside Posts: 365	15.06.2005 - 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 Administrator Legends never die Registered: Aug 2003 Location: nö Posts: 25422	15.06.2005 - 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" , 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 Legend Legend Registered: May 2004 Location: outside Posts: 365	15.06.2005 - 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 Bloody Newbie Registered: Feb 2005 Location: FH Hagenberg Posts: 12	15.06.2005 - 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 Administrator Legends never die Registered: Aug 2003 Location: nö Posts: 25422	18.06.2005 - 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

Ruby on Rails

Forum Index > Software > Coding Stuff

funka

gue

COLOSSUS

Rektal

X3ll

Troy

funka

watchout

derelict

mat

derelict

mat

derelict

cypher

mat