Bedzie sie dzialo... Rails 3.1 i 3.2

Dyskusje
41

[quote=PaK]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 :wink: woleli widac miec jeden, sprawny, skonsolidowany i wokol tego jednego budowac biznes. Ezra rozwija ta swoja firme hostingowa, a DHH pisze ksiazki :wink: sam zobacz ze oni juz nie sa zainteresowani budowaniem swojego programistycznego ego… ida dalej[/quote]
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…

42

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.[/quote]
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. Nic z tych rzeczy.

Chyba?[/quote]
A działa? No to pokaż że działa. Nawet nie ma na liście opcji w generatorze. Jest wymieniony tylko AR.[/quote]
Powtórzę się: poczytaj o tym, a dopiero później się czepiaj, że nie działa. Po pierwsze nie rozgraniczasz 2 rzeczy. ActiveModel != generatory. ActiveModel to interfejs dzięki któremu railsy mogą wszystkie ORMy traktować tak samo (np. przy generowaniu formularzy). I to działa bez problemów. Generatory możesz sobie doinstalować jako gemy - dlaczego railsy niby mają udostępniać generatory do wszystkich ORMów?

Tak to zawsze można było zrobić. Tylko po co wtedy helpery?[/quote]
Wydaje mi się, że znowu nie do końca wiesz o czym piszesz… 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)

Żeby było prościej podam przykład. W czasach 2.3 jeżeli chciałeś zrobić remote_form_for, to używałeś tego helpera i generował się inline javascript w prototypie. W tym momencie można dodać do form_for atrubut :remote => true i generują się tylko odpowiednie atrybuty w HTMLu. I możesz dorzucić obsługę tych atrybutów w dowolnym frameworku (tutaj implementacja dla jqueru: http://github.com/rails/jquery-ujs/blob/master/src/rails.js)

To po co helpery? Tak zawsze można było pisać.[/quote]
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.

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ć.

Moje zdanie jest takie, że później takim kodem ciężej zarządzać, ale zgodzę się, że to może być kwestia gustu i przyzwyczajenia, więc może inaczej:
widziałem panel administracyjny, w którym w tabelce był zrobiony inline editing i użyte kilka innych helperów js (chociażby zwykły link_to z :method => :delete, to też generuje sporo kodu). Strona była cięższa o 100 czy 200 kb. Widzisz jakiś sposób na łatwe odchudzenie stron z dużą ilością javascriptu korzystając z helperów z rails 2.3?

43

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?

44

Napisalem ci dlaczeo, a ty dalej sie produkujesz o kodzie jednego i drugiego frameworka. Rails mialo wieksze community, dluzszy staz i wiecej wdrozen IMHO nikt by sie nie zgodzil na to co ty od poczatku pronujesz z Rails Core Team. Kilka lat starszy projekt jest porzucany na rzecz nowego ? Docelowo Merb i Rails to to samo. Nikt nie potrzebuje 2 takich samych frameworkow zjadajacych sie nawazajem, wiedzieli ze lepiej sie polaczyc. Do Rails core-team dolaczyc jedynie yehuda. Nawet kadrowo wyglada to smiesznie, a ty ciagl bedziesz o tym kodzie. Kod juz przepisali… zostaje gdybanie.

45

Srsly, chce Wam się jeszcze?

46

47

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

48

Pojechałbym, ale zdaje się że Jarek jest kreacjonistą, więc flejm mógłby być za mocny :wink:

49

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.[/quote]
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.

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ę.

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?

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

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.

Moje zdanie jest takie, że później takim kodem ciężej zarządzać,[/quote]
Ciężej? Przecież Ruby jest o wiele łatwiej debugować niż JavaScript. :slight_smile: 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

Ź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.

50

Oj, chyba siebie przeceniasz. :slight_smile: Naprawdę chcesz abym wypróbował wartość twoich argumentów na rzecz ateizmu czy ewolucjonizmu?

51

A co community ma do tego? Przecież tu nikt nie mówił o porzucaniu jakiegoś projektu. Lub inaczej, oba zostaną porzucone, i zastąpione przez RoR3. Chodziło tylko o sposób dojścia do tego docelowego. Ale faktycznie, to niewiele teraz znaczy. Było, minęło. Jestem ciekaw czy Merb faktycznie wchłonie się w RoR3 czy będzie zachowywał swoją odrębność. Bo to, że RoR2 zostanie porzucony i zastąpiony przez RoR3, to pewne.

52

Projekty obecnie działające pod Rails 2.3 będzie można odpalić w 3.0 po bardzo niewielu bardzo niewielkich zmianach (Czak na ostatnim WRUGu robił to na żywo).

To jest absolutny killer w dalszej dyskusji, przynajmniej jak dla mnie. Wolę poczekać pół roku dłużej i mieć framework, na który mogę łatwo zmigrować, niż mieć pół roku wcześniej framework, w którym mógłbym co najwyżej rozpocząć nowy projekt.

53

No, ale dobrze pamiętam, że obiecywano że zmigrowanie z RoR2 do RoR3 ma być tak samo proste jak z Merba1 do RoR3. No chyba, że z tego się wycofano… ktoś to kiedykolwiek odwołał, czy ta obietnica pozostaje w mocy? Oczywiście wiadomo, że przy bardziej złożonym projekcie nie musi być to banalne.

54

Ja widzę i nawet używam: mongomapper i ripple (do riaka). Ale jak tam wolisz.

Ech… cały czas pisaliśmy o używaniu helperów, tak? Ale już nie mam dalej siły tłumaczyć, skoro dalej nie widzisz zalet.

Gdzie ja napisałem, że trzeba? Dałem Ci nawet linka do gotowej implementacji dla jquery. Napisałem, że można łatwo napisać dla dowolnego frameworka, ale do prototype i jquery już są, a w niedługim czasie będą zapewne też do reszty… Ale jak widać wolisz bić pianę na forum niż poczytać i samemu zobaczyć jak to działa.

55

Oho, nawet Stoicki Drogomir traci cierpliwosc :wink:

56

Właściwie to nie wiem po co dalej się produkuję :wink:

Ode mnie EOT, żeby już nie tracić czasu na głupoty :stuck_out_tongue:

57

Nie chcę już kontynuować bezsensownej dyskusji, ale:

Dla nieznających merba, opis merb parts: http://wiki.merbivore.com/howto/parts

Jako, że mam zjazd i mam dużo nudnych zajęć ;-), to postanowiłem spróbować:

Wszystko zamyka się w 40 linijkach, nie ma oczywiście pełnej funkcjonalności merb parts, ale podstawowe renderowanie akcji działa, reszta to tylko kilka dodatkowych godzin szlifowania kodu.

Przykład użycia w widoku do dopisanego unit testu: http://github.com/drogus/rails-parts/blob/master/test/views/foo/index.html.erb

Jak będę miał więcej czasu (niestety pewnie nie będę miał, ale kto wie), to może nawet zrobię z tego coś używalnego :wink:

58

No fajnie, bardzo fajnie :). Ale w jaki sposób sobie byś poradził np. z tym żę jeden part renderuje stronę 1, a chcesz mieć np. ajaxową paginację albo inną interaktywną funkcję? Trzeba i tak postawić oddzielny kontroler. Tym sposobem wracamy do render_component ;).

59

Partsy powinny być dużo lżejsze (ale trzeba by to potwierdzić benchmarkami) z prostego powodu: nie mając całego narzutu kontrolerów w postaci callbacków i parsowania requestu. Podejrzewam, że moją prostą implementację też można by jeszcze odchudzić (np. wrzucić swoją własną implementację Rendering).

W tym wypadku dużo lepiej używać partsów wszędzie tam gdzie jest to opłacalne (a jest wiele takich miejsc w każdej aplikacji) i jeżeli trzeba zrobić z tego akcję ajaxową, to dać:

class ArticlesController < ApplicationController def index render :text => part(ArticlesPart => :index, :some => "params") end end

60

Nie wiem czy suchar, bo dawno sie nie udzielałem.

Powstała już niezła “nakładka” na Arel:

http://metautonomo.us/projects/metawhere/