Temat: Przekonajcie mnie do RoR ;)

Lada moment zacznę pracę nad sporym serwisem. Od jakiegoś czasu czaję się też na RoR, w międzyczasie przekopując się przez "Programming Ruby" Thomasa, Fawlera i Hunta.
I teraz mam dylemat. Albo napiszę ten serwis "standardowo", w PHPie, albo rzucę się na to z RoRem. Wiadomo, że najlepiej poznać nową technologię na głębokiej wodzie. ;)

Jednak o RoR wiem na chwilę obecną bardzo mało i nie wiem czy w ogóle będzie mi się to podobało.
Kluczowe we wszelakiego rodzaju frameworkach są dla mnie dwie rzeczy:

1. Absolutna kontrola nad kodem wynikowym strony. Chcę aby wyglądał on dokładnie tak jak ja to zaplanuję. Żadnych wrzucanych bez mojej wiedzy i zgody javascriptów, żadnych dodatkowych znaczników, żadnych komentarzy czy własnego formatowania. Framework ma mi po prostu wypełnić treścią dostarczony szablon.

2. Pełna dowolność w kształtowaniu bazy danych. Wiem, że RoR wymaga specyficznego nazywania tabel i pól w bazach. To jestem w stanie przełknąć. Ale chciałbym nie musieć kombinować, gdy przyjdzie mi ochota na pobranie sporej ilości danych ze skomplikowanej, znormalizowanej bazy.

Czy RoR będzie mi w tym przeszkadzał, czy pomoże?
Jeśli napiszecie coś jeszcze, w czym mógłby mi pomóc, będę dźwięczny. Na pewno w końcu i tak go przetestuję, kwestia tylko czy wbijać się już teraz, czy zostawić go na mniej ważny projekt.
Dodam, że serwis, który mam na myśli ma bardzo wysoko postawioną poprzeczkę jeśli chodzi o dostępność. Stąd potrzeba pełnej kontroli nad kodem wynikowym.

Temat: Przekonajcie mnie do RoR ;)

Edward Łuska:
Jednak o RoR wiem na chwilę obecną bardzo mało i nie wiem czy w ogóle będzie mi się to podobało.

Bedzie, ale nie w tym rzecz.

Kluczowe we wszelakiego rodzaju frameworkach są dla mnie dwie rzeczy:

1. Absolutna kontrola nad kodem wynikowym strony. Chcę aby wyglądał on dokładnie tak jak ja to zaplanuję. Żadnych wrzucanych bez mojej wiedzy i zgody javascriptów, żadnych dodatkowych znaczników, żadnych komentarzy czy własnego formatowania. Framework ma mi po prostu wypełnić treścią dostarczony szablon.

RoR renderuje szablony, ktore Ty tworzysz, nic nie zrobi za Twoimi plecami.

2. Pełna dowolność w kształtowaniu bazy danych. Wiem, że RoR wymaga specyficznego nazywania tabel i pól w bazach. To jestem w stanie przełknąć.

RoR domyslnie przychodzi z ORM w postaci ActiveRecord, nie wymaga on uzywania zadnych specyficznych nazw tabel/pol, jedynie z gory zaklada pewne konwencje, z ktorych mozesz, ale nie musisz korzystac.

Ale chciałbym nie musieć kombinować, gdy przyjdzie mi ochota na pobranie sporej ilości danych ze skomplikowanej, znormalizowanej bazy.

Nic nie stoi na przeszkodzie, zebys to robil.

Czy RoR będzie mi w tym przeszkadzał, czy pomoże?

Pomoze.

Jeśli napiszecie coś jeszcze, w czym mógłby mi pomóc, będę dźwięczny. Na pewno w końcu i tak go przetestuję, kwestia tylko czy wbijać się już teraz, czy zostawić go na mniej ważny projekt.

RoR + masa wtyczek = 50% potrzebnej funkcjonalnosci w wiekszosci typowych przypadkow, jednak bedziesz musial poswiecic sporo czasu na optymalizacje i tweakowanie to tu, to tam, lecz mimo to prace beda postepowac znacznie szybciej niz w przypadku PHP.

Dodam, że serwis, który mam na myśli ma bardzo wysoko postawioną poprzeczkę jeśli chodzi o dostępność. Stąd potrzeba pełnej kontroli nad kodem wynikowym.

"kod wynikowy" bedziesz mial pod pelna kontrola, to akurat nie powinno Cie martwic. Jedynym powaznym problemem moze byc hosting Twojej aplikacji, chyba, ze bedziesz mial dedykowany serwer dla potrzeb projektu.Piotr Solnica edytował(a) ten post dnia 20.02.08 o godzinie 22:12

Temat: Przekonajcie mnie do RoR ;)

Kwestia serwera jest jeszcze do przegadania. Również statystyki oglądalności obecnej wersji serwisu dopiero dostanę, więc w tej chwili jeszcze nie wiem na jakie obciążenie będę się musiał szykować.

Z tymi nazwami tabel właśnie o konwencje mi chodziło.

Dzięki za pocieszające wieści. ;)

Temat: Przekonajcie mnie do RoR ;)

To ja trochę "zniechęcę" ;)
Jasne, że najlepiej poznawać nową technologię na głębokiej wodzie.

Ale przy RoR trzeba zdecydowanie wyrzucić do kosza pehapowe przyzwyczajenie "jedna strona dokumentacji - pisanie - jedna strona - pisanie itd.". Railsy wymagają najpierw poznania filozofii, struktury i bibliotek - zarówno Ruby'ego, jak i samego frameworku.

Jeśli ktoś jest DOBRYM programistą PHP (zna obiekty, wzorce itd.), to chyba właśnie ta konieczność odrobienia lekcji z teorii przed siądnięciem do praktyki jest najtrudniejszym doświadczeniem przy wchodzeniu w świat Railsów.

I niech Cię sam Matz broni przed napisaniem własnego "błyskotliwego" rozwiązania problemu, którego najpierw nie poszukałeś dogłębnie w API RoR ;)