i wszystko jest ok, dziala jak ma dzialac, a problem zaczyna sie gdy dodawana jest nowa kategoria w trybie produkcyjnym. (po restarcie server-a jest ok)
Probowalem to objesc przez wywołanie - Rails.application.reload_routes!, zaawansowane constraints, ale bez efektu.
params[:id] niekoniecznie musi być liczbą, to może być równie dobrze string (właściwie to zawsze jest string, ewentualnie zawierający tylko liczbę ;)) a dla modelu ganz egal czy zrobisz
[code=ruby]Model.find(1)
czy
Model.find(‘foo-bar’)[/code]
to co próbujesz zrobić jest a) złe b) niemożliwe. na produkcji routes są generowane przy starcie aplikacji i musiałbyś się pewnie nieźle nagimnastykować żeby je przeładować (tylko po co?!).
damian: też nie rozumiem problemu. Jeżeli chodzi Ci o to, żeby ten route nie przysłonił zwykłych ścieżek, to musisz go dać z najniższym priorytetem, tzn. na samym dole pliku. Jedyna większa różnica jest taka, że przy takiej konfiguracji dostaniesz wyjątek RecordNotFound, a przy takiej, którą chciałeś uzyskać, router nie będzie umiał znalźć ścieżki. Dla użytkownika to nie ma znaczenia, więc nie ma chyba różnicy co zastosujesz.
Właściwie to może być ku temu jeden dobry powód - jeżeli masz bardzo duży plik routes.rb, a chcesz, żeby ten url był otwierany jak najszybciej, to może mieć to sens. Ale podejrzewam, że to jest bardzo mały procent takich przypadków i dodatkowo sama akcja musiałaby być bardzo szybka, bo inaczej różnica w routingu nie ma znaczenia (np. w porównaniu z dostępem do bazy danych).
A więc, żeby wyjśnić, applikacja oprata jest o refinery cms gdzie jest bardzo duzo własnych enginów z własnymi routsami.
Routsy dane są z najmniejszym priorytetem (na samym dole pliku) i po to jest dane constraints, żeby łapało to tylko wyznaczonych ścieżek, a nie wszystko jak leci, bo refinery generuje swoje ścieżki. Mam nadzieje że to rzuciło nowe światło na problem i mi własnie chodzi dokładnie o ta dodatkową gimnastyke, inaczej zamieściłbym to pytanie w zielonej szkole