1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-15 03:12:41 +01:00
phorge-phorge/src/applications/transactions/editfield/PhabricatorEditField.php

300 lines
6.9 KiB
PHP
Raw Normal View History

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
abstract class PhabricatorEditField extends Phobject {
private $key;
private $viewer;
private $label;
private $aliases = array();
private $value;
private $hasValue = false;
private $object;
private $transactionType;
private $metadata = array();
private $description;
private $editTypeKey;
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
public function setKey($key) {
$this->key = $key;
return $this;
}
public function getKey() {
return $this->key;
}
public function setLabel($label) {
$this->label = $label;
return $this;
}
public function getLabel() {
return $this->label;
}
public function setViewer(PhabricatorUser $viewer) {
$this->viewer = $viewer;
return $this;
}
public function getViewer() {
return $this->viewer;
}
public function setAliases(array $aliases) {
$this->aliases = $aliases;
return $this;
}
public function getAliases() {
return $this->aliases;
}
public function setObject($object) {
$this->object = $object;
return $this;
}
public function getObject() {
return $this->object;
}
public function setDescription($description) {
$this->description = $description;
return $this;
}
public function getDescription() {
return $this->description;
}
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
abstract protected function newControl();
protected function renderControl() {
$control = $this->newControl();
if ($control === null) {
return null;
}
$control
->setValue($this->getValueForControl())
->setName($this->getKey());
if (!$control->getLabel()) {
$control->setLabel($this->getLabel());
}
return $control;
}
public function appendToForm(AphrontFormView $form) {
$control = $this->renderControl();
if ($control !== null) {
$form->appendControl($control);
}
return $this;
}
protected function getValueForControl() {
return $this->getValue();
}
protected function getValue() {
return $this->value;
}
public function setValue($value) {
$this->hasValue = true;
$this->value = $value;
return $this;
}
public function generateTransaction(
PhabricatorApplicationTransaction $xaction) {
$xaction
->setTransactionType($this->getTransactionType())
->setNewValue($this->getValueForTransaction());
foreach ($this->metadata as $key => $value) {
$xaction->setMetadataValue($key, $value);
}
return $xaction;
}
public function setMetadataValue($key, $value) {
$this->metadata[$key] = $value;
return $this;
}
protected function getValueForTransaction() {
return $this->getValue();
}
public function getTransactionType() {
if (!$this->transactionType) {
throw new PhutilInvalidStateException('setTransactionType');
}
return $this->transactionType;
}
public function setTransactionType($type) {
$this->transactionType = $type;
return $this;
}
public function readValueFromRequest(AphrontRequest $request) {
$check = array_merge(array($this->getKey()), $this->getAliases());
foreach ($check as $key) {
if (!$this->getValueExistsInRequest($request, $key)) {
continue;
}
$this->value = $this->getValueFromRequest($request, $key);
return;
}
$this->readValueFromObject($this->getObject());
return $this;
}
public function readValueFromObject($object) {
$this->value = $this->getValueFromObject($object);
return $this;
}
protected function getValueFromObject($object) {
if ($this->hasValue) {
return $this->value;
} else {
return $this->getDefaultValue();
}
}
protected function getValueExistsInRequest(AphrontRequest $request, $key) {
return $this->getValueExistsInSubmit($request, $key);
}
protected function getValueFromRequest(AphrontRequest $request, $key) {
return $this->getValueFromSubmit($request, $key);
}
public function readValueFromSubmit(AphrontRequest $request) {
$key = $this->getKey();
if ($this->getValueExistsInSubmit($request, $key)) {
$value = $this->getValueFromSubmit($request, $key);
} else {
$value = $this->getDefaultValue();
}
$this->value = $value;
return $this;
}
protected function getValueExistsInSubmit(AphrontRequest $request, $key) {
return $request->getExists($key);
}
protected function getValueFromSubmit(AphrontRequest $request, $key) {
return $request->getStr($key);
}
protected function getDefaultValue() {
return null;
}
protected function getListFromRequest(
AphrontRequest $request,
$key) {
$list = $request->getArr($key, null);
if ($list === null) {
$list = $request->getStrList($key);
}
if (!$list) {
return array();
}
return $list;
}
public function getHTTPParameterType() {
return 'string';
}
public function setEditTypeKey($edit_type_key) {
$this->editTypeKey = $edit_type_key;
return $this;
}
public function getEditTypeKey() {
if ($this->editTypeKey === null) {
return $this->getKey();
}
return $this->editTypeKey;
}
public function getEditTransactionTypes() {
$transaction_type = $this->getTransactionType();
$type_key = $this->getEditTypeKey();
// TODO: This is a pretty big pile of hard-coded hacks for now.
$edge_types = array(
PhabricatorTransactions::TYPE_EDGE => array(
'+' => pht('Add projects.'),
'-' => pht('Remove projects.'),
'=' => pht('Set associated projects, overwriting current value.'),
),
PhabricatorTransactions::TYPE_SUBSCRIBERS => array(
'+' => pht('Add subscribers.'),
'-' => pht('Remove subscribers.'),
'=' => pht('Set subscribers, overwriting current value.'),
),
);
if (isset($edge_types[$transaction_type])) {
$base = id(new PhabricatorEdgeEditType())
->setTransactionType($transaction_type)
->setMetadata($this->metadata);
$strings = $edge_types[$transaction_type];
$add = id(clone $base)
->setEditType($type_key.'.add')
->setEdgeOperation('+')
->setDescription($strings['+'])
->setValueDescription(pht('List of PHIDs to add.'));
$rem = id(clone $base)
->setEditType($type_key.'.remove')
->setEdgeOperation('-')
->setDescription($strings['-'])
->setValueDescription(pht('List of PHIDs to remove.'));
$set = id(clone $base)
->setEditType($type_key.'.set')
->setEdgeOperation('=')
->setDescription($strings['='])
->setValueDescription(pht('List of PHIDs to set.'));
return array(
$add,
$rem,
$set,
);
}
return array(
id(new PhabricatorSimpleEditType())
->setEditType($type_key)
->setTransactionType($transaction_type)
->setValueType($this->getHTTPParameterType())
->setDescription($this->getDescription())
->setMetadata($this->metadata),
);
}
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
}