Panie Tomashu, dawaj ta prezke na następnym wrugu ;]
Tylko ja mam dość mieszane uczucia odnośnie Deface? Okej, jest to użyteczne narzędzie do robienia zmian w enginach (widokach), ale też ma swoje wady. Przede wszystkim jest to proteza a nie rozwiązanie problemu z architekturą Railsów i tego jak obsługują pluginy.
W idealnym świecie, chciałbym sobie wziąć plugin, zmodyfikować routing, kontrolery i widoki, o ile się da poprzez mechanizm dziedziczenia. Wtedy obyło by się bez brzydkich (IMHO) hacków w stylu Deface czy https://github.com/svenfuchs/routing-filter .
Tak przy okazji, używam obu narzędzi, fajnie że są i działają, mniej fajnie że są w ogóle potrzebne.
Dobrze Hubert, i jak byś to rozwiązał dla widoków? Serio i bez złośliwości, po prostu nie wyobrażam sobie pomysłu na rozwiązanie tego problemu lepszego niż to zastosowane w Deface?
Przy obecnym podejściu, gdzie widoki są brane jako pliki, wykonywane (w dużym uproszczeniu podobnie jak skrypty PHP) i zwracany jest String – nie ma na to szans. Jeśli chcielibyśmy robić to czyściej, widoki w takim stylu powinny być zastąpione obiektami, generującymi bloki HTML w metodach, poprzez jakiś ładny DSL. Taki widok odpowiadałby na metodę render(), i sklejał HTML. Widok taki mógłby używać instancji innych widoków do renderowania “partiali”.
Dobry krok w tym kierunku już jest zrobiony, poprzez użycie prezenterów.
Jeśli tego typu podejście było by zastosowane w Railsach, szczególnie w pluginach, wtedy bierzesz widok, dziedziczysz z niego, wskazujesz kontrolerowi że ma użyćn owej klasy, w której to zmieniasz fragmenty kodu które Cię interesują.
Routing to drugi problem, równie mocno wymagający jakiegoś rozwiązania co widoki w Railsach.
EDIT: O, coś jak to http://erector.rubyforge.org/userguide.html
To już jest zrobione
https://rubygems.org/gems/minimal
I powiem Ci tak: właśnie siedzę w dużym projekcie, korzystającym z Minimal (opartym mocno na Adva-* enginach). Developerzy mają tego gema dość, wpinanie się w minimalowe klasy jest upierdliwe w pisaniu i utrzymaniu. Po pokazaniu im Deface ustalili, że będą na to przechodzić.
Po prostu: traktowanie widoków jako klas to poroniony pomysł. Brzmi pięknie w teorii, ale jest koszmarem w implementacji. Widok HTML-owy to nie jest klasa (z jej dziedziczeniem itd.) – to jest drzewo. Tym samym o wiele większą przyszłość ma biblioteka zorientowana na jak najwygodniejszą manipulację tym drzewem.
(inb4 lispowcy mówiący że kod też jest drzewem 
)
+1
Presentery i widoki w postaci klas z bardzo głupimi szablonami w stylu mustache czy handlebars, to fajna rzecz, żeby wypakować logikę tam gdzie jej miejsce, ale traktowanie samej klasy jako szablonu, gdzie generuje HTML jest średnim pomysłem. Zobacz zresztą na javascript - czy przyszło by Ci kiedyś do głowy, żeby pisząc aplikację frontendową generować HTML używając klas i nadpisywać go dziedzicząc po nich? Takie podejście może działać tylko wtedy kiedy klasy będą na trochę wyższym poziomie i nie będziesz tam definiował bezpośrednio HTMLa. Tylko takie podejście też ma dużo wad, pierwsza to, że nie masz wtedy HTMLa takiego jakiego chcesz, tylko takiego jakiego Ci wygeneruje biblioteka.
Ok, spójrzmy na frameworki desktopowe/mobilne: Cocoa, Qt , Android (bo te znam w miarę dobrze). Zazwyczaj jest możliwość stworzenia widoków na 2 sposoby:
- Poprzez narzędzie w stylu visual builder, bądź/oraz wyedytowanie sobie pliku widoku w XMLu
2, Stworzenie widoku programistycznie.
W każdej z możliwości, możemy w klasach potomnych modyfikować te widoki programistycznie (o ile ma to sens) bądź stworzyć sobie zupełnie nowy plik szablonu zastępując stary.
Wydaje mi się również że klasa powinna być nazywana widokiem, plik z HTMLem/HAMLem/etc – szablonem.
Zachowajmy szablony, ze względów które Tomasz czy Piotrek przedstawili powyżej (łatwość edycji). Dodajmy za to klasy widoków, w których będzie zawarta logika potrzebna do wyrenderowania tego widoku, modyfikacji/zastąpienia szablonów odziedziczonych czy – programatycznego stworzenia widoku, w DSLu rodem z Erectora. Tutaj jest miejsce dla deface i podobnych rozwiązań.
Jeśli używamy szablonów, powinny być one dość małe (odpowiadać partialom) i idealnie – bez logiki.
Przy takim rozumowaniu mamy zarówno możliwość edytowania widoków przez “front-end developerów”, o ile stosujemy szablony, oraz zwiększaja się szanse na ponowne użycie kodu który już napisaliśmy, w elegancki, zorientowany obiektowo sposób.
I tak, wydaje mi się że szablony muszą pozostać. Pisząc w Objective-C na iPhone, staram się użyć generowanych widoków gdzie jest to możliwe, ale mam sensowne rozwiązane dziedziczenie/modyfikowanie widoków.
Irrelevant.
Ale wtedy musisz traktować widok nie jako HTMLowych node’ów tylko bardziej zbiór widgetów z jakimś layoutem itp. itd. Zobacz sobie np. na Sproutcore 1.x i dlaczego ma wysoką barierę wejścia.
Też mnie trochę denerwuje nazewnictwo railsów
Nie do końca rozumiem w jaki sposób chcesz w praktyce połączyć te podejścia, więc przydałby się przykład 
Piotrek, daj spokój, dyskutujesz z pociągnięciem analogii pomiędzy HTMLem (i generowaniem tegoż) a bibliotekami widżetów.