W jaki sposob moge wyswietlic na stronie spis plikow wykorzystanych do wyrenderowania widoku ?
Chodzi o to ze osoba zajmujaca sie cieciem strony / css, grafika itp musi dosyc czesto “grzebnac” w plikach layoutu, widoku lub partiala, ze wzgledu na rozne aliasy w config/routes nie zawsze po url’u w pasku przegladarki jest oczywiste ktory aktualnie layout jest wyswietlany, lub ktory widok jest wykorzystany.
Czy jest jakas mozliwosc pobrania tych informacji bezposrednio z aplikacji Rails w locie, tak aby je wsztrzyknac w partiala i wyswietlic na stronie ? Tak zeby grafik widzial, w ktory plik ma wejsc zeby mogl namieszac ?
Wystarczy mi sama informacja skad te informacje pobrac, dane do widoku sobie sam wprowadze.
Layout powinienes miec w @_layout, co do reszty, to nawet ciezko bylo by sie wstrzelic w kod rederingu przez MP, jest on strasznie zasyfiony od poczatku samego rails i dopiero w Rails 3.0 widac swiatelko w tunelu na lad i porzadek redneringu widokow i partiali (wiekszosc pracy zostala juz wykonana). Narazie zostaje tylko logger.
Albo 1 h rozmowa z grafikiem na temat jak działa Rails i gdzie powinien szukac template’ow dla danego url’a.[/quote]
Tak, na pewno mu wytlumaczysz, zwlaszcza jak masz aliasy albo inne cuda na kiju w routingu
Tak jak pisalem wczesniej, nie zawsze mozna latwo odczytac layout w zaleznosci od url’a.
Chocby layouty przelaczane (osobny layout dla zalogowanego/niezalogowanego), na pewno grafik zrozumie ze trzeba przejsc do kontrollera, znowu ktorego ;), i sprawdzic nazwe layoutu (przyjmujac ze zrozumie choc troche kod, ktory ten layout przelacza), pytanie tylko po co ?
Grafik tez sie nade mna nie zneca i nie kaze mi pisac hakow pod kIEpskiego
Uszanujmy wiec prace grafikow i ulatwmy im troche zycie
def write(message)
@buffer << message
end
def write?
true
end
alias_method(:info, :write)
alias_method(:info?, :write?)
alias_method(:fatal, :write)
alias_method(:fatal?, :write?)
end
def in_logger @old_rails_logger = RAILS_DEFAULT_LOGGER
Object.const_set “RAILS_DEFAULT_LOGGER”, DummyLogger.new
true
end
def out_logger
Object.const_set “RAILS_DEFAULT_LOGGER”, @old_rails_logger
end[/code]
Kod jest hardcorowy i nie zalecany w srodowiskach produkcyjnych
Wstawiasz to do ApplicationController, powiniens miec przy kazdej akcji 2 logi o renderingu (layout/akcja) i 2 warningi Niestety z uwagi na zbyt wielka pojebanosc ActionView nie udalo mi sie w zaden sposob nadpisac logger’era ta aby wylapywac info o renderingu partiali.
Prosciej chyba bedzie nadpisac BufferedLogger tak aby wrzucal buffor do jakiejs zmiennej w momencie jej ustawienia.
def flush
@guard.synchronize do
unless buffer.empty?
old_buffer = buffer
@log.write(old_buffer.join)
@second_buffer << old_buffer.join if @second_buffer
end
# Important to do this even if buffer was empty or else @buffer will
# accumulate empty arrays for each request where nothing was logged.
clear_buffer
end
end
end
end[/code]
A to do ApplicationController
[code] before_filter :in_logger
def in_logger @action_log = []
logger.second_buffer = @action_log
end[/code]
Potem juz tylko wystarczy w layoucie dac
Polecam też plugin footnotes, który to w stopce dodaj linki właśnie do aktualnie renderowanego widoku, wywołanego kontrollera, parametrów sesji i kilka innych przydatnych informacji. W dodatku można skonfigurować go, tak aby po klikniecie w link “Widok” automatycznie otwierał nam renderowany widok w naszym edytorze :]
Korzystam z friendly_id dla potrzeb SEO, w development.log mam cala mase zapytan typu
SELECT * FROM slugs WHERE (slugs.sluggable_id = 194 AND slugs.sluggable_type = ‘Category’) ORDER BY id DESC LIMIT 1
Zapewne jest to spowodowane tym iz w widoku w petli wywoluje linkt_to(category.name, category_path(category))…
Nic by w tym dziwnego nie bylo, gdyby nie fakt, iz bez rails-footnotes strona laduje sie blyskawicznie (localhost), natomiast z rails-footnotes, strona otwiera sie prawie 10 sekund, samych zapytan do bazy jest ponad 200, ktore lacznie trwaja tyle czasu.
Uno: Dlaczego rails-footnotes tak znacznie wydluza czas dostepu do bazy danych ?
Secundo: Jak usprawnic czesanie kategorii z bazy zeby tak po niej nie rzezbic podczas generowania linka do kategorii ? (Wiem ze nie na temat, ale nie chce zakladac nowego watku z tym samym problemem, jesli kogos razi w oczy to wyedytuje i przeniose)
Zakładając, że istnieje asocjacja slug. To pobierze w dodatkowym zapytaniu sluga dla wszystkich pobranych kategorii. Poczytaj więcej o :include w dokumentacji railsów, to jeden z najprostszych i najczęściej stosowanych zabiegów optymalizacyjnych.
Dziekuje drogus za podpowiedz, po dluzszej zabawie udalo mi sie zminimalizowac liczbe zapytan do 12tu.
Mam jeszcze cos takiego w logach:
[quote]SELECT * FROM slugs WHERE (slugs.sluggable_id = 29 AND slugs.sluggable_type = ‘Category’) ORDER BY id DESC LIMIT 1
SELECT * FROM slugs WHERE (slugs.sluggable_id = 187 AND slugs.sluggable_type = ‘Category’) ORDER BY id DESC LIMIT 1
SELECT * FROM slugs WHERE (slugs.sluggable_id = 162 AND slugs.sluggable_type = ‘Category’) ORDER BY id DESC LIMIT 1
SELECT * FROM slugs WHERE (slugs.sluggable_id = 10 AND slugs.sluggable_type = ‘Category’) ORDER BY id DESC LIMIT 1[/quote]
Widac ze bierze to z nastepujacego widoku (mam 4 produkty w bazie):
<% for product in @products_puls %>
<li>
<div class="thumbnail">
<%= link_to_unless_current(image_tag(product.photo.url(:thumb)),product_path(product)) %>
</div>
<div class="info">
<%= link_to_unless_current(product.name,product_path(product)) %>
<span class="cat"><%= link_to_unless_current(product.category.name,category_path(product.category)) %></span>
</div>
<div class="clear"></div>
</li>
<% end %>
Gdzie @products_puls
wyglada tak:
def products_puls
@products_puls = Product.find(:all, :include => :slugs)
end
Da sie sensownie zminimalizowac te cztery zapytania ? Bo jesli produktow byloby 100, to jak rozumiem poszloby 100 zapytan do bazy ?
proboowalem:
def products_puls
@products_puls = Product.find(:all, :include => [:slugs,:category])
end
Ale nic to nie dalo… oczywiscie Product belongs_to :category oraz Category has_many :products
Z gory dziekuje za cenne wskazowki,
Pozdrawiam
P.S Zapomnialem dodac, iz powyzsze logi wyczesalem wygodnie za pomoca rails-footnotes
A dlaczego masz :include => :slugs dla produktu? Możesz wkleić tutaj asocjacje jakie masz w modelach?
Update: i jeszcze jedno pytanie - dlaczego właściwie trzymasz slugi w oddzielnej tabeli? ma to jakieś zalety, które przykrywają czasożerność (dodatkowe zapytania) i skomplikowanie (dodatkowy model, dodatkowy kod jako :include chociażby) ?
Niestety z uwagi na zbyt wielka pojebanosc ActionView nie udalo mi sie w zaden sposob nadpisac logger’era ta aby wylapywac info o renderingu partiali.