CODEWITHSUNDEEP
xpages
Fernando Rodriguez
Fernando Rodriguez

Reputation: 25

Xpages don´t refresh changes

Scenario: IBM Domino for 2 developers. Developer A modify a xpage....., when he preview in web browser the changes aren´t reflected. Developer B preview in web browser, and the changes aren´t reflected. Developer B open the xpage and see the changes, but not in preview in browser.

If developer B save the xpage both developers preview the changes.

The problem is only for developer A, and is only for xpages, the rest of the components works well in web.

The build and the clean doesn´t change anything. We reinstall the domino designer & client, doesn´t work.

We use the id of the administrator and the behavior is the same.

Any ideas?

Thanks

Upvotes: 1

Views: 959

Answers (2)

Johann Echavarria
Johann Echavarria

Reputation: 9945

Exactly the same behaviour happened to me (with developer A and developer B) and it was something really simple: Developer A doesn't had selected the option "Project" > "Build Automatically" and Developer B had it.

@tim recommended:

NEVER enable "Build Automatically"

In that case, developer B must be aware to click on build project in order to preview the changes.

I haven't had problems with "Build Automatically" so far, but is good to know.

Upvotes: 0

Tim Tripcony
Tim Tripcony

Reputation: 8086

Additional information would be needed to discover the root cause of this behavior, but here are some general guidelines I've found to be best practice that may also assist in this case:

  1. NEVER use "Preview in Web Browser". It lies to you: even if it "works", the environment it's running in is similar to a real Domino server, but it's not a Domino server. Unless every user of the application will be launching the app by using "Preview in Web Browser" from their own Designer client, this mode is not fully representative of what the users will experience. Using it to unit test the application, therefore, is counter-productive, because what you're seeing is similar to what the users will see, not what they will see. Instead, open the same browser your users will be using and manually navigate to the URL of the test application. Whenever you've made changes, just refresh the browser window. That will give you representative results.

  2. NEVER enable "Build Automatically". It feels convenient to be able to immediately test your changes after you save, but the two extra mouse-clicks required to manually perform a build between saving and testing are worth the removal of inconsistent behavior caused by "Build Automatically".

  3. ALWAYS develop against a local replica. Even if you're running a local development server on your machine (which is highly recommended), Designer performs a massive amount of unnecessary work when it's connected to a Domino server, even if there's no actual network traffic required to connect to that server. Develop against a local replica, and after each build, replicate to your test server -- whether that server is also on your local machine or a "real" server somewhere else. This, again, feels like an extra step, but provides significantly better results.

  4. ALWAYS use some form of version control when developing an XPage application as a team, even if the team is just two developers. Whether it's Git or Mercurial or Subversion or something else entirely, the best way to avoid unnecessary bloodshed is to ensure each developer is testing against separate replicas of the application that are all linked to the same version control repository. With proper branching, this approach not only allows you to revert to previous versions of design elements as needed or desired, but also allows you to decide when to merge another developer's changes into your own, rather than risking overwriting each other's changes every time you replicate -- or, if you aren't following the above recommendation, immediately when you save.

There are many factors that can cause the behavior you're reporting, such as signer permissions (which it sounds like you already ruled out), and multiple signers in the same application (to test this, just sign the entire design immediately prior to doing a build, then test the page again). But from the content of your question, I suspect that the four recommendations I listed above will drastically improve your development process, even if they don't address the root cause of this specific behavior.

Upvotes: 10

Related Questions