Implement a basic version of ApplicationEditor in Paste
Summary:
Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste.
This mostly looks and works like ApplicationSearch, and is heavily modeled on it.
Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else.
This has no functional changes, except:
- I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it.
- Subscribers are now editable.
- Form field order is a little goofy (this will be fixed in a future diff).
- Subscribers and projects are now race-resistant.
The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits.
Test Plan:
- Created pastes.
- Created pastes via API.
- Edited pastes.
- Edited every field.
- Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4768, T9132
Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhabricatorSelectEditField
|
|
|
|
extends PhabricatorEditField {
|
|
|
|
|
|
|
|
private $options;
|
|
|
|
|
|
|
|
public function setOptions(array $options) {
|
|
|
|
$this->options = $options;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getOptions() {
|
|
|
|
if ($this->options === null) {
|
|
|
|
throw new PhutilInvalidStateException('setOptions');
|
|
|
|
}
|
|
|
|
return $this->options;
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function newControl() {
|
|
|
|
return id(new AphrontFormSelectControl())
|
|
|
|
->setOptions($this->getOptions());
|
|
|
|
}
|
|
|
|
|
2015-11-04 14:05:10 +01:00
|
|
|
protected function newHTTPParameterType() {
|
|
|
|
return new AphrontSelectHTTPParameterType();
|
2015-11-03 14:38:06 +01:00
|
|
|
}
|
|
|
|
|
2015-12-15 15:57:32 +01:00
|
|
|
protected function newCommentAction() {
|
|
|
|
return id(new PhabricatorEditEngineSelectCommentAction())
|
|
|
|
->setOptions($this->getOptions());
|
2015-12-04 16:56:03 +01:00
|
|
|
}
|
|
|
|
|
2015-12-16 14:09:21 +01:00
|
|
|
protected function newConduitParameterType() {
|
|
|
|
return new ConduitStringParameterType();
|
|
|
|
}
|
|
|
|
|
Implement a basic version of ApplicationEditor in Paste
Summary:
Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste.
This mostly looks and works like ApplicationSearch, and is heavily modeled on it.
Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else.
This has no functional changes, except:
- I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it.
- Subscribers are now editable.
- Form field order is a little goofy (this will be fixed in a future diff).
- Subscribers and projects are now race-resistant.
The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits.
Test Plan:
- Created pastes.
- Created pastes via API.
- Edited pastes.
- Edited every field.
- Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4768, T9132
Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
|
|
|
}
|