-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overwriting Page Logic #164
Comments
I can't recreate this. Are you sure you are using the latest version of the client? Should be |
Are you sure you are not doing:
As that would have this effect. |
I was watching on a screen sharing session - so I can't be positive. I will On the other hand this general issue is the number one issue for newbies. It would seem to me that we would be better off implementing a simple merge
I'm not entirely clear of the current history recreation code, and we may On Saturday, 18 June 2016, Paul Rodwell notifications@github.com wrote:
|
In WardCunningham/Smallest-Federated-Wiki#431 (comment) @WardCunningham reflected that:
I don't think this was followed up on at the time. The underlying problem is really that it is possible to overwrite a page with an implicit fork. While there may be times when this has the desired outcome, it has consequences when it is not. By making ALL implicit forks go to local storage, we can protect from the harm that the implicit fork to the origin server can cause. The user can always undo the action by removing the page from local storage, or do an explicit fork if that is what they really want. |
I'm sorry to see this useability trap rear it's ugly head again. Our goal has been to allow organization to emerge by relocating paragraphs to pages later made to hold them once the subject of that page has been recognized. Thus dragging a paragraph from one page to another changes both. The drag logic has been hacked to avoid self-destructive situations that occur when dragging a paragraph from an earlier revision of the same page. The drag logic does not consider it an error to reorganize content held by another site. Should I decide that the organization of your pages could be improved by a move, I make that move and implicitly fork both pages to my own in the act. By this second interpretation, two implicit forks to local storage should be expected when one doesn't have write access to the origin. I am not in favor of abandoning refactoring, even for the often damaged welcome page. I do see two improvements that have been discussed but remain unimplemented.
The more we think of federated wiki as a tool to be used rather than an experiment to be performed, the more priority these improvements deserve. Aside: This case has many similarities to the trap in unix where an accidental space in |
After rereading @opn's initial observation carefully I can agree that the inopportune order of writes is likely the case. The logic in question is in handleDragging registered in refresh. https://github.com/fedwiki/wiki-client/blob/master/lib/refresh.coffee#L49-L87 This function is called twice, once each for source and destination. The order of these calls is determined by jQuery-UI and is, as I recall, the destination first, then the source. Subsequent processing is asynchronous and thus subject to reordering. The logic on line 67 tries to recognize and ignore the case where they are different copies of the same page. This is the hack I mentioned above. |
After rereading @paul90's suggestion I see it as a possible implementation of "Save deleted pages" that we haven't considered before. Our url syntax includes three synonyms for the origin domain name, On further thought, Paul is suggesting that the newer page be stored local, not the page it is about to replace. We have some precedent for this when a page goes local when one forgets to login. But we also use ghost pages for Transport results that are not stored anywhere except that they appear in the lineup. The user interface for deleting |
I like ghost pages. They are innovative, and clear. When overwriting a page of the same name by fork, or dragging an item - It has the advantage of:
It may also prepare a precedent for deleting, or other modifications of On Saturday, 18 June 2016, Ward Cunningham notifications@github.com wrote:
|
@opn's most recent suggestion addresses the confusing situation when forking an earlier version (ghosted) from history leaves two conflicting versions side by side with no indication which is currently stored. Better to ghost any version that has become obsolete by an action elsewhere in the lineup. Imagine browsing five revisions side by side. Fork any one and the others will relinquish currency by becoming ghost. There would be no other current page since none other would have the most recent fork action showing in its journal. |
Dragging and dropping a link / paragraph from one page to another results in a strange precedence logic in that the page dragged from is registered as the most recent change and over-writes the page where the content was dropped.
I have not tried reproducing this, but file this issue now to raise the general issue of over-writing the Welcome Visitors page which is the most common mistake / bug newbies face.
The sequence of events I just observed was:
The result is that your own page has been replaced by the foreign Welcome Visitors page and all your content on that page lost.
The text was updated successfully, but these errors were encountered: