Большое обновление :
Когда я наконец нашел реальное решение, я также обнаружил реальную проблему. Поскольку я записал здесь много бесполезной информации, учитывая реальную проблему, я делаю огромное обновление этого вопроса, чтобы другие люди могли легко найти, что происходит, и увидеть решение.
Проблема :
Это из-за активов конвейера Rails 3.1
На самом деле ... Это очень просто: активы были обработаны дважды в среде разработки. Многочисленные исследования показали, что мой сервер Rails 3.1 рендерил ресурсы из папок «app / assets» и «public / assets». Итак, у меня были дублированы все файлы .js и .css, что нарушало все мои анимации javascript (да ... привязка дважды одного и того же события и обработчика к одному и тому же элементу - это не то, что вам нужно ... обычно).
И если проблема возникла внезапно, это произошло потому, что мне пришлось запустить «rake assets: precompile» для развертывания моего приложения. С тех пор, когда мое приложение работало в разработке, сервер рендерил статические предварительно скомпилированные ресурсы и динамические предварительно скомпилированные активы.
Решение (теперь на несколько строк ниже) - но вы все равно можете прочитать его
Первый: мне просто нужно было удалить все скомпилированные ресурсы из моей общей папки.
Лучше: добавьте config.serve_static_assets = false в development.rb, что предотвратит загрузку файлов из / public / assets. Также не забудьте сбросить кеш браузера.
[Редактировать: 20 июля 2012 г.]
Продвинутый: у меня недавно была новая проблема из-за этих статических активов. Вы знаете, когда вы используете скрепку или другой драгоценный камень, и они добавляют ваши изображения в вашу общую папку в какую-то системную подпапку , потому что лучше, если вы захотите развернуть свое приложение, используя capistrano. Ну, это здорово, но! Поскольку мы добавили config.serve_static_assets = false, эти изображения не отображаются в процессе разработки, и это плохо, если вы хотите выполнить для них некоторые CSS. Так! Что делать тогда?
Ну, на самом деле вам нужно будет включить статические ресурсы в разработке, например:
# Expands the lines which load the assets
config.assets.debug = true
config.serve_static_assets = true
Затем, чтобы предотвратить повторное рендеринг других ресурсов (предварительно скомпилированных) рельсами, просто выполните следующую команду:
rake assets:clean
Это противоположность rake assets: прекомпилируйте и очистите вашу папку public / assets, чтобы Rails не рендерил ваши активы дважды. Конечно, вам все равно придется очищать кеш браузера и очищать ресурсы каждый раз, когда вы их предварительно компилируете.
[Редактировать: 18 ноября 2013 г.] - От @idejuan ответа
Другое решение:
Вы можете добавить эту строку:
config.assets.prefix = '/dev/assets'
Для development.rb, где префикс может быть любым, что вы хотите. Скрипты больше не будут загружаться дважды, и изображения в / public / system будут прочитаны! Но будьте осторожны, так как он меняет путь к вашим «статическим» ресурсам ... если вам требуются ресурсы из драгоценного камня, он может не загружать их должным образом при разработке ...
[Конец редактирования]
Оставшийся вопрос с ответом!
Хорошо, почему мое приложение для разработки отображало статические предварительно скомпилированные активы?
Фактически, если вы прекомпилируете свои ресурсы локально, рельсы по умолчанию отображают ресурсы из общей папки И из папки ресурсов в среде разработки и тестирования. Обычно ресурсы из общей папки должны перезаписывать ресурсы из папки активов, но это не так, и даже если это произойдет, мы потеряем преимущества «debug_mode», поскольку нам придется каждый раз прекомпилировать ресурсы. Итак ... Ресурсы отображаются дважды при предварительной компиляции локально в среде разработки и тестирования.
Итак, добавив «config.serve_static_assets = false» в ваш файл development.rb, вы каким-то образом перезапишете строку по умолчанию, которая говорит Rails искать ресурсы в вашей общедоступной папке. Я надеюсь, что они однажды сделают что-нибудь более чистое с локально скомпилированными активами.
Спасибо тем, кто помог мне в моих исследованиях :).
Кулгар.