Ruby on Rails PL Forum

Strzałek napisał:

Mnie w Railsach od zawsze denerowało to że w sumei nie mam wyboru odnośnie ORM'a.

Że co?

Strzałek napisał:

Bardzo się ucieszę jeżeli bez żadnego bólu od tearz będę mógł podpiąć Sequela bądź DataMappera zamiast ActiveRecord'a.

Byłoby miło, Sequel wymiata ze składnią, używa się go o wiele milej niż AR.

Ostatnio edytowany przez arturek (2010-02-15 09:35:46)

hubertlepicki napisał:

Aha. Z tym że nie wiem czy droga wybrana przez Rails 3.0 jest najbardziej właściwa. Jeśli chcesz aby Twój ORM był wspierany to i tak musi kwakać ja k ActiveRecord. A już pojawia się opór i to wśród tak bliskich konceptowo ORMów jak MongoMapper...

Możesz rzucić linka do tego oporu? ;-) Na razie się nie spotkałem, więc nie wiem jakie są minusy (sam na razie nie widzę żadnych, ale to pewnie dlatego, że nie pracowałem na razie z mongomapperem).

Co do kwakania. Interfejs, który musi być zaimplementowany w ActiveModel jest naprawdę minimalny. Dosłownie kilka metod typu new?, errors, table_name itp. (chyba, że coś się bardzo pozmieniało ;P)

hipertracker napisał:

Jedyne, co krytykowałem to sposób w jaki podeszli do implementacji RoR3, tzn. zaczęli od złej strony. Gdyby wzięli za bazę bebechy Merba zamiast RoR2, to już od dawna by była finalna wersja Rails3.

Du^H^H^H... spekulacja!

Rails 3 jest już za rogiem. W tym przypadku nie wiem czy słusznie oceniasz efekt końcowy i sposób jego osiągniecia gdy nie posiadasz zadnego empiryczngo narzędzia aby dowieść swojej teorii oraz Rails 3.0 nie ujrzało jeszcze światła dziennego jako release.

Chyba trochę koloryzujesz

hipertracker napisał:

Spekulacja? Wystarczy policzyć ile miesięcy zajęło dodanie do RoR2 tego, co już dawno było w Merbie 1.x...

Wystarczy policzyć? Czekam na wyliczenia w takim razie, myślę, że inni też chętnie usłyszą.

Pytałem się przez Twittera Yehudy, ale nic nie odpowiedział, czy RoR3 ma, lub planuje mieć jakiś odpowiednik merbowych Parts.

Parts można przy obecnej architekturze napisać w kilkudziesięciu linijkach. Jak będę miał trochę czasu w weekend, to mogę spróbować, zobaczymy co z tego wyjdzie.

Co z tego, że można w RoR3 pod URL wpiąć aplikację Rack? Czyż RoR2 tego nie potrafi wpiąć sobie cały framework Sinatry  przez metal controllers?

Oczywiście, że potrafi, ale nie w tak prosty i elegancki sposób.

Albo kwestia ActiveModel. Dużo szumu o nic. Merb od samego początku potrafił używać dowolnego ORM'a. RoR3 w końcu też do tego doszedł po półtora roku prac...

A to już jest demagogia dla ludzi, którzy nigdy nie spojrzeli w kod merba. Merb nie miał wsparcia dla dowolnego ORMa, tylko dla Sequela, DataMappera i AR (i oczywiście wszystkich innych ORMów z takim samym interfejsem jak którykolwiek z wymienionych). Jeżeli ORM ma inny interfejs, to np. helpery Merbowe się wypną na owego ORMa tak samo jak do tej pory robiły to helpery Railsowe.

I chyba to jeszcze nie działa w pełni.

Chyba? Source or it doesn't exist.

To samo obietnica pozbycia się Prototype. To tez chyba jeszcze nie działa w pełni.

Chyba? Jedyne co zapewniają Railsy 3 w kwestii integracji z javascriptem to zestaw klas i atrybutów dołączanych do generowanego HTMLa. Jak chcesz możesz sobie napisać do tego obsługę w czystym javascripcie. Nie wiem gdzie tutaj obietnica pozbycia się prototype'a może nie działać. Może chodzi Ci o to, że plik js do obsługi jquery jeszcze nie działa w pełni? Tego nie wiem, ale jeżeli nie, to tylko kwestia dni/tygodni aż ktoś to zrobi, wbrew pozorom takie bindingi są dość proste do napisania.

Poza tym już w RoR2 można było podmienić helpery JS aby korzystały z JQuery (choć za pomocą plugina).

Przy czym dalej wtedy miałeś burdel w kodzie z powrzucanym wszędzie inline javascriptem. I nie było łatwego sposobu, żeby zaimplementować ten javascript tak jak Ty tego chcesz.

Albo koncepcja pluginów jako gemów. Merb to miał od początku.

Z tego co pamiętam, to merb miał bardzo dużo problemów z gemami. Nie raz i nie dwa straciłem na rozwiązywaniu tych problemów sporo czasu. Może jestem za cienki w łokciach, ale w sieci widziałem też sporo podobnych problemów, co pozwala sugerować, że nie był to jednostkowy przypadek.

Fakt, że dodano Bundlera (i dobrze) ale dodano to równocześnie do Merba 1.x. Więc w sumie RoR3, choć idzie w dobrym kierunku, to na tle Merba nie ma się czym szczególnym pochwalić.

Trudno, żeby się chwalić czymś, co można dodać do dowolnego projektu napisanego w Ruby.

Tomash napisał:

Przyczyna może być jedna z dwóćh, a jej zidentyfikowanie jest niezbędne do podjęcia dalszych kroków:
1) Yehuda Katz, współautor Merba i kontrybutor do Railsów (oraz jeszcze parę innych osób zamieszanych w fuzję), trochę lepiej niż Ty i ja (niż całe to forum podejrzewam) ogarnia oba te frameworki i trochę lepiej wie ile pracy wymagałoby przerobienie Railsów 2.x, a ile Merba 1.0 na Rails 3.0. Na podstawie czego podjął optymalną decyzję.

Yehuda nie podjął żadnej  decyzji. On jest tylko wykonawcą woli swojego pracodawcy (Ezry) i to on raczej zadecydował razem z DHH.

Tomash napisał:

Weź nie opisuj Railsów jako spieprzonego od strony programistycznej frameworka, bo mi krecią robotę w ten sposób robisz

I tak na tle wszystkich pehapowych frameworków to Rails błyszczy jak złoto. Choć wcześniej popełniono parę błędów, to nigdy bym nie powiedział że cały RoR jest spieprzony. Choć sam przyznasz, że gdyby nie było trochę spieprzone to by, jak to napisałeś, nie było potrzebne "kompletnie przepisywanie Railsów z przeszczepaniem kodu z Merba". Merb nie potrzebował żadnego "kompletnego przepisania z przeszczepianiem kodu z Rails".  To bardziej Rails miał co pożyczać od Merba, a nie odwrotnie.

Ale generalnie od Ror 2.3.x jest już nieźle. Zresztą sam sobie piszę jedną aplikację w Ruby 1.9 i RoR3.0b (z AR i Arelem) i jak na razie nie mogę narzekać. Czekam tylko kiedy wyjdzie RSpec 2 (dopiero v2 ma być zgodna z RoR3)

drogus napisał:

hipertracker napisał:

Spekulacja? Wystarczy policzyć ile miesięcy zajęło dodanie do RoR2 tego, co już dawno było w Merbie 1.x...

Wystarczy policzyć?

Wystarczy pomyśleć i przeczytać ze zrozumieniem. Kupę czasu zajęło dodawanie do RoR tego co było gotowe w Merbie. Np. kwestia optymalizacji wydajnościowej, modularność, ORM agnostic, lepszy router itp. itd.

drogus napisał:

hipertracker napisał:

Co z tego, że można w RoR3 pod URL wpiąć aplikację Rack? Czyż RoR2 tego nie potrafi wpiąć sobie cały framework Sinatry  przez metal controllers?

Oczywiście, że potrafi, ale nie w tak prosty i elegancki sposób.

No dobrze, ale to są w sumie drobiazgi, a nie jakaś zasadnicza zmiana jakościowa.

drogus napisał:

Merb nie miał wsparcia dla dowolnego ORMa, tylko dla Sequela, DataMappera i AR (i oczywiście wszystkich innych ORMów z takim samym interfejsem jak którykolwiek z wymienionych).

Acha, dodali wsparcie do ORM których na razie nie ma, ale które może powstaną? Bo ja nie wiem jakie inne ORM masz na myśli.

drogus napisał:

hipertracker napisał:

I chyba to jeszcze nie działa w pełni.

Chyba?

A działa? No to pokaż że działa. Nawet nie ma na liście opcji w generatorze. Jest wymieniony tylko AR.

drogus napisał:

hipertracker napisał:

To samo obietnica pozbycia się Prototype. To tez chyba jeszcze nie działa w pełni.

Chyba? Jedyne co zapewniają Railsy 3 w kwestii integracji z javascriptem to zestaw klas i atrybutów dołączanych do generowanego HTMLa.

Chodziło mi o helpery, wymianę RJS aby śmigało z jQuery a nie Prototype.

drogus napisał:

Jak chcesz możesz sobie napisać do tego obsługę w czystym javascripcie.

Tak to zawsze można było zrobić. Tylko po co wtedy helpery?

drogus napisał:

wbrew pozorom takie bindingi są dość proste do napisania.

To po co helpery? Tak zawsze można było pisać.

drogus napisał:

hipertracker napisał:

Poza tym już w RoR2 można było podmienić helpery JS aby korzystały z JQuery (choć za pomocą plugina).

Przy czym dalej wtedy miałeś burdel w kodzie z powrzucanym wszędzie inline javascriptem. I nie było łatwego sposobu, żeby zaimplementować ten javascript tak jak Ty tego chcesz.

Burdel? Chyba tylko dla  podglądacza wygenerowanego kodu HTML w przeglądarce. Kogoś to obchodzi? Istotne jest to, że dobrze napisane helpery w praktyce skracają czas pracy.

drogus napisał:

Albo koncepcja pluginów jako gemów. Merb to miał od początku.

Z tego co pamiętam, to merb miał bardzo dużo problemów z gemami.

Dlatego jest Bundler który nie tylko działa z RoR3b1 ale także z Merbem 1.x. Chodzi jednak o samą koncepcję, gemami łatwiej zarządzać niż pluginami w RoR 2.x.

PaK napisał:

Merb nie mial tylu pluginow, helperow i bibliotek co Rails w momencie podejmowania decyzji. Rails natomaist mialo marke, kupe materialow, duza blogosfere, webcasty, pluginy, dzialajace produkcyjne aplikacje (ile tego bylo w tym merbie?), renome, gigantyczne community skupione wokol jednego konkretnego frameworka. Przedewszysktim juz od wersji 0.13 wdrozenia, wdrozenia i jeszcze raz wdrozenia.

Juz ci to kilka razy tlumacyzlem poltora roku temu... doprowadzenie merb'a do punktu w ktorym bylo rails to jeszcze conajmnije 3-4 lata (nie tylko w sensie stricte kodu ale calego srodowiska, wszystkich tych rzeczy ktorych nie zmienic wydajnoscia ani liniami kodu), doprowadzenie rails do punktu w ktorym byl merb, to tylko refaktoryzacja.. zajelo widac ponad rok.

Ezra z DHH dobrze wiedzieli o tym ze na koncu osiagna ten sam framework w taki czy inny sposob, ale kosztem tego ze beda 2 frameworki woleli widac miec jeden, sprawny, skonsolidowany i wokol tego jednego budowac biznes. Ezra rozwija ta swoja firme hostingowa, a DHH pisze ksiazki sam zobacz ze oni juz nie sa zainteresowani budowaniem swojego programistycznego ego... ida dalej

Chyba się nie rozumiemy.  Dwa frameworki Rails2 i Merb1 miały się scalić we wspólnym, jednym  frameworku po nazwą Rails 3.0, prawda? Z tego logicznie wynika, że Rails 3.0 = Merb 2.0 i to  Yehuda Katz wyraźnie stwierdził: "Effectively, Merb 2 is Rails 3".

Na tym tle to, coś napisał jest bez sensu. Bo od strony kodu, do Rails 3 można było dojść zarówno poprzez bazowy kod Rails 2, jak i bazowy kod Merba 1. Zasadniczo nie ma różnicy. Ale tu jest jeden problem.  Wiadomo, że  Merb 1 miał dużo lepszą (i bliższą planowanego Rails 3) implementację niż Rails 2. Modularność? W Merbie1 jest dużo lepsza niże w Rails2. Router? Też lepszy. Agnostyczny ORM? Od początku Merb planowano aby był agnostyczny. Optymalizacja wydajnościowa? Od samego początku Merb był pisany z nastawieniem na wysoką wydajność. Itd. Skoro więc Merb 1 i Rails 2 miały i tak stać się wspólnym Rails 3 to czyż nie logiczniej było aby to zrobić na bazie kodu Merba 1? Kupę rzeczy by już było. Można by tylko się skupić na ulepszeniach, jakie miał wprowadzać Rails 3. Zamiast rozgrzebywać kod Rails2 można było ulepszyć Merba1 i nazwać to Railsem 3. Przecież o to tu chodzi: o połączenie się tych dwóch na wyższym poziomie. Jeden i drugi framework musiał być przebudowany, tylko że Rails2 wymagał wielokrotnie więcej pracy. Pytam się więc: po jaką cholerę refactorowano RoR2 aby w ogóle dojść do poziomu Merba1? Przecież celem jest Rails 3 (aka Merb 2).

W tym wszystkim interesuje mnie czy Rails 3.0 będzie miał kilka rzeczy które widzę tylko w Merbie.

Np. parametry formalne w metodach kontrolerów a nie wszystko przez hasza params. Albo Parts czy jakiś odpowiednik komponentów. Wkurza mnie że nie ma jasnego planu tego co ma wylecieć, a co zostać z RoR2 i Merba1...

Albo czy Rails 3 pozbędzie się głupiego (odziedziczonego po Rails 2) wyjątku DoubleRenderException?  W Merbie ten problem nie istnieje, bo po prostu metoda kontrolera zwraca ostatnie wyrażenie i nie trzeba żadnych magicznych metod renderowania. To też ułatwia pisanie komponentów, składanie kodu z kaskady wywołań. W Rails 2 to jest b. trudne właśnie z powodu tego zakazu wywołania 2x metody render. To jest kiepski design.

Żeby było jasne: jestem zwolennikiem i popieram oczywiście rozwój Rails 3. Obawiam się tylko, że z rozpędu, Rails 3 odziedziczy kilka niezby dobrych rozwiązań z Rails 2. Jak choćby to, co wyżej napisałem. Do tego by nie doszło gdyby refaktorowano zamiast Rails 2, Merba 1...

Z mojego punktu widzenia łatwiej było wyjść od Rails 2 gdyż miało większą bazę kodu i testów. Z tego co kojarzę to Merb był mniejszym projektem (funkcjonalnie i rozmiarowo) - mogę się mylić bo nigdy nie używałem. Jednak gdybym ja miał to samo zadanie do zrobienia postąpiłbym tak samo, gdyż w procesie refaktoryzacji zawsze mógłbym odpalić te wszystkie kobylarne testy rails (no trochę ich tam jednak mają prawda?) i sprawdzić czy wciąż wszystko działa i czy nic się nie zepsuło. I tak krok po kroku, commit po commicie wciąż mógłbym sprawdzać konsekwencje wszystkich swoich decyzji. W drugą stronę dodawać nowe funkcjonalności do Merba z Railsów, szukać dla nich testów, przepisywać by działały z Merbem... Może ja to sobie wszystko źle wyobrażam ale co o tym sądzicie?

Ostatnio edytowany przez paneq (2010-03-26 08:56:46)

Srsly, chce Wam się jeszcze?

:-) Az zatesniklem za IRC #rubyonrails.pl i tymi godzinami spedzonymi na klutniach o ateizmie, ewolucji, kreacjonizmie itd ;-) czasami tam było jak na #religia.pl ;-)

drogus napisał:

hipertracker napisał:

Acha, dodali wsparcie do ORM których na razie nie ma, ale które może powstaną? Bo ja nie wiem jakie inne ORM masz na myśli.

Może najpierw poczytaj trochę o co w ActiveModelu chodzi i zobacz jak wyglądał kod merba, bo w tym momencie nie wiem co mam odpisać.... Oczywiście, że nie ma innych ORMów niż trzy wymienione. Bazy dokumentowe i obiektowe nie istnieją. A jak nawet istnieją to *na pewno* nie ma do nich ORMów.

ROFTL! O czym ty piszesz? Od kiedy to baza obiektowa potrzebuje ORM'a?? Wiesz w ogóle co to jest ORM? Może myślisz że do Magleva też trzeba będzie pisać ORM'a? Mapowanie obiektowo-relacyjne to atrapa dająca namiastkę obiektowości dla płaskich tabel baz relacyjnych (RDBMS). Baza obiektowa nie potrzebuje żadnych takich atrap, bo pracuje bezpośrednio na samych obiektach.

ActiveRecord to też nazwa popularnego, prostego wzorca projektowego gdzie mapowane są tabele RDBMS na klasy, a kolumny na atrybuty klasy. Zobacz zresztą na nowe API
w AR: where, join, sort, group itp. Toż to są  terminy żywcem wzięte z SQL'a. Nie mówię, że to źle. Po prostu AR i Arel jest silnie związany z RDBMS. Składnia Arela nijak ma się do baz obiektowych, grafowych czy dokumentowych. Już jakieś większe szanse ma DataMapper, bo oparty jest na bardziej ogólnym wzorcu projektowym (gdzie może wpinać się do różnych źródeł, nie tylko RDBMS, ale także np. strumienia XML). Tylko, że jak użyjesz prawdziwej bazy obiektowej to nie potrzeba żadnych takich atrap. Po prostu pracujesz z klasami Ruby'ego zupełnie przezroczyście. Tak ma Maglev.

Czyli, podsumowując. Dobrze że zrobili ActiveModel. Dobrze dla AR i Sequela, trochę mniej DataMappera. To wszystko. Nie widzę większych zastosowań ponad te trzy ORM. Czyli trochę to sztuka dla sztuki. Zrobil to co od początku potrafił Merb, tylko trochę bardziej ogólnie i czasochłonnie.

drogus napisał:

[dlaczego railsy niby mają udostępniać generatory do wszystkich ORMów?

No bo to logiczne, że jeśli są równouprawnione. Widocznie nie są. Nadal preferowany jest AR. Merb nie preferuje, możesz sobie wybrać generator do ORM'a. Czyli jest tu bardziej agnostyczny. Ale może to w końcu też dodadzą w RoR3, na co liczę.

drogus napisał:

W tym momencie możesz używać helperów i w tym samym czasie dopisać obsługę w dowolnej bibliotece js. Jak chciałbyś to zrobić w railsach 2.3? (bo piszesz, że zawsze się dało)

Banalnie. Pisałem nawet o tym w swojej książce. Po prostu tworzysz HTML i już. Do tego wpinasz sobie kod JS w jQuery czy czymkolwiek. Czy ja musze szaleć z helperami aby stworzyć prosty tag HTML z danymi atrybutami? Przecież to każde dziecko potrafi. Główną zaletą helperów RoR2 było to, że odwalały za ciebie dodatkową robotę. To, że był to inline JS jest nieistotne z perspektywy oszczędności czasu developera. Teraz masz te same helpery w RoR3 które nic nie robią. Musisz podpiąc się ręcznie w JS i napisać logikę którą RoR2 dawał za darmo. Wcześniej mając gotowy formularz, wystarczyło dodać remote_ i już działał "ajaksowo", a jeśli JS był wyłączony w przeglądarce, to działał standardowo. Teraz trzeba to wszystko samemu napisać w JS. Wiem, że to nie jest trudne, ale mimo wszystko. RoR3 mogłby w tych helperach dać opcjonalnie możliwość generowania inline JS jak w RoR2. Wtedy każdy miałby to co chce. Mógłby zacząć z helperami inline JS a potem prawie nie zmieniając kodu w Ruby, dodać sobie samodzielną obsługę JS. Jak będzie miał na to czas. Bo czasu nigdy za wiele, prawda?

drogus napisał:

Do tej pory railsy nie wspierały generowania odpowiednich atrybutów i nie było jednego standardu, dlatego nie można było w prosty sposób dodać na przykład rails.yui.js, który działałby dla wszystkich aplikacji railsowych.

Eee tam. Czyli chodzi tylko o "standard nazewnictwa"? Śmieszne. Zwłaszcza że przy okazji RoR3 usunął logikę jaką wcześniej dawał za darmo RoR2.

drogus napisał:

Co do podmiany prototype na jquery jeszcze: jeżeli twierdzisz, że podmiana pliku javascriptowego, który ma 100-200 linijek nie jest żadnym krokiem wprzód w porównaniu do monkey patchowania railsowych helperów w pluginie, to nie wiem jakich argumentów mam użyć.

To są wszystko pierdoły. Włączasz gzip na serwerze HTTP i masz silną kompresję i te linijki są niczym. Poza tym, trzeba tego używać "z głową". Ja bym użył helperów w fazie początkowej, bo zapewniają mi szybką logikę której nie muszę pisać. A dopiero później, bym sobie przełączył na eventy i własny kod JS. Przedwczesna optymalizacja to zło.

drogus napisał:

hipertracker napisał:

dobrze napisane helpery w praktyce skracają czas pracy.

Moje zdanie jest takie, że później takim kodem ciężej zarządzać,

Ciężej? Przecież Ruby jest o wiele łatwiej debugować niż JavaScript. W wypadku GWT masz potężne javowe IDE z debuggerem. Google nie bez powodu tego użyło do napisania GMaila. Lift generuje nie tylko kod Javacriptu ale także XHTML, nie tylko AJAX ale także

hipertracker napisał:

Widzisz jakiś sposób na łatwe odchudzenie stron z dużą ilością javascriptu korzystając z helperów z rails 2.3?

Źle mnie zrozumiałeś. Ja nie jestem przeciwko używaniu nieinwazyjnego JS. Ale jak aplikacja ma naprawdę silnie używać JS to ja bym od razu sięgnął po całe komponenty JS, np. framework Ext.JS czy googlowy Closure.