Temat: Kod do widoków trzymany w bazie.

Kamil Grabowski:
Wersjonowanie tabel: http://wiki.rubyonrails.org/rails/pages/ActsAsVersioned

Co do pomysłu to po kiego? Możesz trzymać sobie content w bazie, ale imho trzymanie całego widoku jest zbędne. Do tego co dorzucił Tomek dodam:

1. Nie zrobisz:

$ grep --color -R SZUKANY_WZORZEC nasz_projekt

2. Twoje rozwiązanie jest trudne w refaktoryzacji, a na pewno upierdliwe
3. Testowanie
4. Bezpieczeństwo
5. Wydajność

po kiego ? .. ustawiam tryb devel

wtedy do kazdego kawalku kodu partiala otaczany jest divem z ramka w ktorej mam link do jego edycji i nazwa..

prototypowac mozna w blysk ciupagi - wlasciwie na stronie aplikacji ukladam co chce.. widac co w czym jest ..
przenoszenie partiali z jednego do drugiego to tez pikus

na raszte twoich punktow odpisze jak sobie z nimi radze / albo moglbym sobie radzic :

1) where content like '%xxx%'; ..

twoje kolorki mi nie beda dzialac na BSD

2) no bardzo trudne i upierdliwe .. teraz zmieniam nazwe partiala - i kazde jego wywolanie w chocby i mocno zagniezdzone jest podmieniane na takie z nowa nazwa

3 linijki kodu

3)co za roznica skad interpreter bierze kod ktory bedzie testowany ? z pliku, z bazy, czy pamieci ?

4) no tak .. kod podawany jako parametr moze budzic obawy

5) tak to prawda... ale cache'uje sie to pewnie tak samo jak by bylo zrobione klasycznie

lubicie podawac bloki kodu jako parametry w rubym ...

ja mialem kaprys zeby podawac je calej aplikacji :]

niektorzy pisza pluginy zeby miec konsole irb w ktorej moga odpytywac czy przedefiniowywac niektore rzeczy

a ja to od dupy strony zrobilem :)

Temat: Kod do widoków trzymany w bazie.

Michał Bogdan:
lubicie podawac bloki kodu jako parametry w rubym ...

ja mialem kaprys zeby podawac je calej aplikacji :]

niektorzy pisza pluginy zeby miec konsole irb w ktorej moga odpytywac czy przedefiniowywac niektore rzeczy

a ja to od dupy strony zrobilem :)

Gratuluję, możesz być z siebie dumny. ;)

Pokaż kod, aż jestem ciekaw - czy to jutrzenka nowego rozwiązania, które spowoduje opad szczęki u wszystkich, czy też antyprzykład jaki ze śmiechem będą sobie rubiowcy przekazywać? ;)Tomasz Stachewicz edytował(a) ten post dnia 13.12.08 o godzinie 12:12

Temat: Kod do widoków trzymany w bazie.

Michał : No i OK. Jeśli jest tak jak mówisz i potrafisz sobie poradzić dobrze z tymi wszystkimi problemami to plus dla Ciebie. Jeśli Ci wygodniej, korzystaj z rozwiązania, które nam przedstawiłeś. Mi wygodniej jest to trzymać w plikach.

Jeśli dobrze zrozumiałem (jeśli nie to mnie popraw) Ty chcesz trzymać całe widoki w bazie danych (łącznie z layoutem). To co teraz powiem to oczywiście kwestia sporna, którą pewnie też można rozwiązać pisząc jakiś edytor czy coś, ale chociażby same pisanie kodu:

1. Pisząc korzystasz z jakiegoś IDE, które koloruje Ci składnie, masz jakieś snippety, skróty klawiszowe.
2. Wciskasz CTRL+S (jabuszko + S, :w itp.) zapisujesz plik, przełączasz się na przeglądarkę, swoim skrótem klawiszowym odświeżasz stronę i w tak w kilka sekund masz wynik swojej pracy. Jeśli poprawiasz szczegóły to tę akcję wykonujesz kilkanaście razy w jednej minucie...

Tak jak mówię rozwiązanie jest tylko drogą, ale liczy się to co jest na jej końcu, czyli efekt/wynik. Dla mnie wygodniejsze jest rozwiązanie z plikami, ponieważ:

- jest proste
- sprawdzone
- prymitywne
- oskryptowane, mam pełno skrótów klawiszowych itp.

Nie mam zamiaru się kłócić nad wyższością jednego rozwiązania nad innym bo rozwiązanie jest rozwiązaniem, a klienci nie płacą za rozwiązanie tylko za końcowy wynik. To w naszej geście jest ułatwiać sobie pracę -> ja ułatwiam sobie trzymając wszystko w plikach do których w super fajny sposób mogę dostać się różnymi narzędziami konsolowymi. :)

Pozdrawiam

Temat: Kod do widoków trzymany w bazie.

Kamil : zgadzam sie z Toba w pelni !!! sam bym duzego produkcyjnego systemu nie odwazyl sie na tym oprzec - bo tak jak sam napisales - nie jest to sprawdzone, a na pewno nie przez setki programistow...

tak .. trzymam w jednym projekcie - cale widoki w bazie

kolejna wazna (dla mnie) zaleta, jaka zauwazam : czesto stajemy przed dylematem - czy dana czesc layoutu powinna byc parametryzowalna, czy nie.. bedzie sie dany kawalek zmienial czy nie ?
parametryzowanie wszystkiego to paranoja, ale czesto potem sie okazuje - ze dajmy na to meta-tagi sa statyczne - a klient, albo pozycjoner chce je zmienic..... albo statyczny byl jakis link w footerze... a trzeba mu zmienic anchora..

a majac cos o czym pisalem
a) nie przejmuje sie tym - ze cokolwiek bedzie sie zmieniac - nawet czesto - a ja nie mam do tego formatki
b) nie musze spedzac czasu by zastanawiac sie, do czego mam doklepac prosty CMS, a do czego nie - oczywiscie rzeczy ktore ewidentnie go potrzebuja - to go dostana - .. a co do calej reszty - to NIC mnie nie ogranicza przy prowadzaniu poprawek (zakladam ze odpalanie IDE, commitowanie,restartowanie serwera to zmudna sprawa - a tym bardziej dopisywanie formatek do jakichs pierdol )

i zdaje sobie sprawe - ze to nie jest dla uzytkownika, ktory dajmy na to wprowadza opisy produktow w serwisie ... - on potrzebuje klasycznego cms

to jest taki gadzet dla kogos kto utrzymuje strone.. a to ze sie pojawiaja problemy z tym, czy z owym - to tylko zalezy od tego, kto na jakie chce isc kompromisy ... no i sporo z tym problemow, to zadne problemy

a co do kwestii tego kto sie chce/ czy nie chce o co spierac .. to ja tez nie chce sie spierac i szkoda ze tak duzo bylo gadania o paranojach/posmiewisku/syndromach czy innych jalowych tematach .. czesto odbierano to, ze odpowiadam - jak sobie radze z roznymi wymienionymi niedogodnosciami - tak jakbym nie wiadomo co sobie uzurpowal ..

pozdrawiam,Michał Bogdan edytował(a) ten post dnia 14.12.08 o godzinie 03:07