Как Вы читаете существующий проект направляющих?
Вы пропустили, чтобы показать нам самую важную часть вашего кода. Было бы намного проще проанализировать ваш код, если бы вы также включили раздел $ .ajax.
Я хотел бы предположить два возможных решения, а также я думаю, что оба эти решения переплетены в вашем случае.
- Процесс Ajax имеет асинхронный характер, что означает, что остальная часть кода не будет ждать его завершения. Это может быть причиной, почему вы иногда видите свой новый контент, а иногда нет. Вероятно, это связано со скоростью вызова AJAX.
Вы пытались сделать это так:
$.ajax({
url: "YOUR ENDPOINT"
}).done(function(html) {
$('#member-profile').hide().empty().html(html).fadeIn();
});
Таким образом, контент будет очищен / заполнен только тогда, когда он будет получен.
- Вторая возможность - это событие самой выставки. В зависимости от скорости, jQuery Mobile может иметь или не иметь времени для предварительного отображения нового HTML-контента и его показа. Если это так, лучше использовать событие pagebeforecreate или pagecreate. Или pageinit, если вы используете более ранние события jQuery Mobile.
9 ответов
Посмотрите на модели. Если бы приложение было записано хорошо, то это должно дать Вам изображение его модели предметной области, которая является, где интересная логика должна жить. Я также смотрю на тесты для моделей.
Способ, которым были реализованы контроллеры/представления, должен быть очевидным только при помощи приложения для направляющих и наблюдения URL.
К сожалению, существует много случаев, где слишком много логических жизней в контроллерах и даже просматривает. Это означает, что необходимо будет смотреть в те каталоги также. Doubley-неудачный, тесты для этих слоев имеют тенденцию быть намного менее ясными.
Сначала я использую приложение, отмечая интересный контроллер и имена действия.
Затем я начинаю читать код для этих контроллеров, и для соответствующих моделей при необходимости. Представления обычно менее важны.
Я сказал бы, смотрят на тесты (или спецификации, если проект использует RSpec) понять на высоком уровне того, что приложение, как предполагается, делает. После того как Вы понимаете от верхнего уровня, как модели/представления/контроллеры, как ожидают, будут вести себя, можно развернуть в реализации.
Если проект направляющих находится в несколько устойчивом состоянии, чем я всегда был большим поклонником использования отладчика, чтобы помочь переместиться по кодовой базе. Я разожгу браузер и начну взаимодействовать с приложением, затем предназначаются для некоторой части функциональности и устанавливают точку останова в начале присоединенной функции. С этим на месте я просто изучаю параметры, входящие в функцию и значение, возвращенное для получения лучшего понимания того, что продолжается. После того как Вы становитесь удобными, можно изменить функциональность немного, чтобы гарантировать, чтобы Вы поняли то, что продолжается. Просто выполнение некоторого статического анализа кода может быть громоздким!Удачи!
Я могу думать о двух причинах посмотреть на существующее приложение, с которым у меня нет предыдущей связи: Я должен внести изменение, или я хочу понять один или несколько аспектов, потому что я рассматриваю использование их, как введено к изменениям, я рассматриваю создание к другому приложению. Я включаю reading-for-education/enlightenment в тот второй случай.
Реальная выгода шаблона MVC и много веб-приложений в целом - то, что они довольно легко разделяются на пар запроса/ответа, которых можно в некоторой степени постигать в изоляции. Таким образом, можно запустить с единственного взаимодействия и вырастить понимание из этого.
При необходимости изменить или расширить существующий код, у меня должна быть хорошая идея того, чем первое изменение будет - если не затем я, вероятно, еще не должен играть с кодом! В приложении для направляющих изменение, скорее всего, включит представление, модель или комбинацию обоих, и я должен смочь определить соответствующие объекты справедливо быстро. Если существуют тесты, я проверяю, что они работают, то пытаются записать тест, который выставляет недостающую функциональность, и далеко мы идем. Если нет никаких тестов затем, это немного более хитро - я собираюсь волноваться, что я мог бы непреднамеренно повредить что-то: я полагал бы, что добавляющие тесты вселяют мне больше веры, которая в свою очередь начнет создавать некоторое понимание области при исследовании. Я должен справедливо быстро смочь войти в red-green-refactor цикл, набрав скорость, поскольку я изучаю свой путь вокруг.
Запустите тесты.:-)
Если Вы удачливы, что это будет основано на RSpec, и это опишет поведение независимо от реализации.
- Я работаю
rake testв терминале - Если среда не загружается, я смотрю на отслеживание стека для выяснения то, что продолжается, и затем я фиксирую его так, чтобы среда загрузила и запустила тесты снова
- Я загружаю сервер и открываю приложение в браузере. Нажатие вокруг.
- Начните работать с задачами под рукой.
- Если код качается, я счастлив. Если код сосет, я повредил его для забавы и прибыли.
Кроме уже отправленных подсказок рабочих спецификаций и разложения MVC, я также как:
rake routes
как другой способ получить высокоуровневое представление всех маршрутов в приложение
./script/console
Направляющие irb консоль являются все еще моим любимым способом осмотреть модели и образцовые методы. Захватите несколько записей и работайте с ними в irb. Я знаю, что это помогает мне во время разработки и теста.
Посмотрите на документацию, существует довольно хорошая документация относительно некоторых проектов. Немного трудно понять код других, но попробовать его... Прочитайте код ;-)