You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FitNesse allows a user to create page names that aren't camel case but these cause problems with Symbolic links. For instance, you can create pages named "Databases" or "Environment1". However if you do this, in several scenarios FitNesse will not work properly.
First, consider the following:
and the following pages setup with environment variables defined and symbolic links to the test suites:
SuiteSetUp works when testing Env A.
It does not work when testing Env 1:
Notice too that the content of Test Page 1 actually gets pulled into the failed link. The page should have the content "Test Page 1", but instead it's just "Page 1" and the word "Test" appears at the end of the Suite Set Up link. It works fine in Env A
Additionally, if you name symbolic links without camelcase names, those fail too.
Results in this failure:
These problems aren't new - they've existed for quite a while.
One other problem I am seeing today with the Oct 10th release and appears new is related to creating SymLinks. I've noticed that if I create new links with a non-WikiWord name, as soon as I click "Create Link" the Properties page refreshes and the link is gone. In practice, the link has been created and if I force a refresh on the normal page, the symlink shows up. Re-opening the Properties page it does not show up, at least not initially. Eventually it does in fact appear on the properties page - it seems to be a caching problem. However I've only noticed this particular caching problem occuring with symlinks named as non-WikiWords - others seem to be working fine. That might be a coincidence because I've only been working with the Oct 10th release a few hours and most of the time has been spent documenting the other issues above. Edit: Scratch that - I've now seen it happen with WikiWord symlinks too. It just seems to be a general caching issue and not related to non-wikiword support.
The text was updated successfully, but these errors were encountered:
Just be clear, this problem didn't just start occurring. It happens with the Aug 14th release and was occurring before that too. I just never got around to documenting it.
FitNesse allows a user to create page names that aren't camel case but these cause problems with Symbolic links. For instance, you can create pages named "Databases" or "Environment1". However if you do this, in several scenarios FitNesse will not work properly.
First, consider the following:
and the following pages setup with environment variables defined and symbolic links to the test suites:
SuiteSetUp works when testing Env A.
It does not work when testing Env 1:
Notice too that the content of Test Page 1 actually gets pulled into the failed link. The page should have the content "Test Page 1", but instead it's just "Page 1" and the word "Test" appears at the end of the Suite Set Up link. It works fine in Env A
Additionally, if you name symbolic links without camelcase names, those fail too.
Results in this failure:
These problems aren't new - they've existed for quite a while.
One other problem I am seeing today with the Oct 10th release and appears new is related to creating SymLinks. I've noticed that if I create new links with a non-WikiWord name, as soon as I click "Create Link" the Properties page refreshes and the link is gone. In practice, the link has been created and if I force a refresh on the normal page, the symlink shows up. Re-opening the Properties page it does not show up, at least not initially. Eventually it does in fact appear on the properties page - it seems to be a caching problem.
However I've only noticed this particular caching problem occuring with symlinks named as non-WikiWords - others seem to be working fine. That might be a coincidence because I've only been working with the Oct 10th release a few hours and most of the time has been spent documenting the other issues above.Edit: Scratch that - I've now seen it happen with WikiWord symlinks too. It just seems to be a general caching issue and not related to non-wikiword support.The text was updated successfully, but these errors were encountered: