Xpages не обновляют изменения

Question

Сценарий: IBM Domino для 2 разработчиков. Разработчик A измените xpage ....., когда он просматривает в веб-браузере, изменения не отражаются. Разработчик B превью в веб-браузере, и изменения не отражены. Разработчик B откройте страницу xpage и просмотрите изменения, но не в предварительном просмотре в браузере.

Если разработчик Б сохранит xpage, разработчики предварительно просмотрят изменения.

Проблема только для разработчика A и предназначена только для xpages, остальные компоненты хорошо работают в сети.

Сборка и чистка ничего не меняют. Мы переустанавливаем дизайнер домино & клиент, не работает.

Мы используем идентификатор администратора, и все поведенческое.

Любые идеи?

Благодаря

Answer 1

Дополнительная информация будет необходима, чтобы обнаружить причину такого поведения, но здесь есть некоторые общие принципы, которые я нашел, чтобы быть лучшей практики, которые также могут помочь в этом случае:

1. NEVER использовать «Предварительный просмотр в веб-браузере». Это вам: даже если он «работает», среда, в которой он работает, составляет , аналогичный для реального сервера Domino, но это не сервер Domino. Если каждый пользователь приложения не запускает приложение, используя «Предварительный просмотр в веб-браузере» со своего клиента-дизайнера, этот режим не полностью отражает то, что пользователи будут испытывать. Таким образом, использование этого модуля для тестирования приложения является контрпродуктивным, потому что то, что вы видите, это аналогично тем, что пользователи увидят, а не то, что они будет. Вместо этого откройте тот же браузер, который будут использовать ваши пользователи, и вручную перейдите к URL-адресу тестового приложения. Всякий раз, когда вы вносили изменения, просто обновите окно браузера. Это даст вам репрезентативные результаты.

2. НИКАКОЕ не включает автоматическую сборку. Удобно сразу же проверять свои изменения после сохранения, но два дополнительных щелчка мыши, необходимые для ручного выполнения сборки между сохранением и тестированием, стоят того, чтобы устранить непоследовательное поведение, вызванное «Build Automatically».

3. ВСЕГДА Разработка против локальной копии. Даже если вы используете локальный сервер разработки на своем компьютере (что очень рекомендуется), Designer выполняет огромную ненужную работу, когда он подключен к серверу Domino, даже если для подключения к этому серверу не требуется никакого сетевого трафика. Разработайте против локальной реплики и после каждой сборки реплицируйте на свой тестовый сервер - независимо от того, находится ли этот сервер на вашем локальном компьютере или «реальном» сервере где-то в другом месте. Это, опять же, похоже на дополнительный шаг, но обеспечивает значительно лучшие результаты.

4. ALWAYS использует некоторую форму контроля версий при разработке приложения XPage в качестве команды, даже если команда состоит всего из двух разработчиков.Будь то Git или Mercurial или Subversion или что-то еще, лучший способ избежать ненужного кровопролития - обеспечить, чтобы каждый разработчик тестировал отдельные реплики приложения, которые все связаны с одним и тем же репозиторием управления версиями. При правильном разветвлении этот подход не только позволяет вам вернуться к предыдущим версиям элементов дизайна по мере необходимости или по желанию, но также позволяет вам решать, когда сменить изменения другого разработчика в свои собственные, а не рисковать переписывать изменения друг друга каждый раз, когда вы реплицируете - или, если вы не следуете приведенной выше рекомендации, немедленно при сохранении.

Есть много факторов, которые могут вызвать поведение вы сообщаете, такие как права доступ подписчиков (который звучит, как вы уже исключили), а также несколько подписантов в одном приложении (чтобы проверить это, просто знак весь проект непосредственно перед выполнением сборки, затем снова проверьте страницу). Но из содержания вашего вопроса я подозреваю, что перечисленные выше четыре рекомендации значительно улучшат ваш процесс разработки, даже если они не будут устранять первопричину этого конкретного поведения.

Answer 2

Точно такое же поведение произошло со мной (с разработчиком A и разработчиком B), и это было что-то очень просто: Developer A не выбрал вариант «Project»> «Build Automatically», и разработчик B имел его.

@ Тим рекомендовал:

никогда не позволит «Build Automatically»

В этом случае разработчик Б должен знать, чтобы нажать на проект сборки, чтобы просмотреть изменения.

У меня не было проблем с «Build Automatically» до сих пор, но это хорошо знать.