1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-04 04:32:43 +01:00
phorge-phorge/src/applications/paste/xaction/PhabricatorPasteLanguageTransaction.php

42 lines
1 KiB
PHP
Raw Normal View History

Modularize application transactions in Paste, mostly Summary: Ref T9789. `Transaction` and `Editor` classes are the last major pieces of infrastructure that haven't been fully modularized. Some of the specific issues are: - `Editor` classes rely on a bunch of `instanceof` stuff in the base class to pick up transaction types like "subscribe", "projects", etc. Instead, applications should be adding these, and third-party applications should be able to add them. - Code is spread across `Transaction` and `Editor` classes somewhat oddly. For example, generating old/new values would probably make more sense at the `Transaction` level, but it currently exists at the `Editor` level. - Both types of classes have a lot of functions based on `switch()` statements, which require a ton of boilerplate and are just generally kind of hard to work with. This creates classes for each type of transaction, and moves almost all of the logic to them. These classes are simpler and more focused than the old stuff was, and can organize related code better. This starts inching toward defining `CoreTransactions` for features shared across applications. It only defines the "Create" transaction so far, but at some point I plan to move all the other shared transactions to Core and let them control which objects they're available for. Test Plan: - Created pastes with web UI and API. - Edited all paste properites. - Archived/activated. - Verified files got reasonable names. - Reviewed timeline and feed. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9789 Differential Revision: https://secure.phabricator.com/D16111
2016-06-10 01:00:06 +02:00
<?php
final class PhabricatorPasteLanguageTransaction
extends PhabricatorPasteTransactionType {
const TRANSACTIONTYPE = 'paste.language';
public function generateOldValue($object) {
return $object->getLanguage();
}
public function applyInternalEffects($object, $value) {
$object->setLanguage($value);
}
private function renderLanguageValue($value) {
if (!strlen($value)) {
return $this->renderValue(pht('autodetect'));
} else {
return $this->renderValue($value);
}
}
Modularize application transactions in Paste, mostly Summary: Ref T9789. `Transaction` and `Editor` classes are the last major pieces of infrastructure that haven't been fully modularized. Some of the specific issues are: - `Editor` classes rely on a bunch of `instanceof` stuff in the base class to pick up transaction types like "subscribe", "projects", etc. Instead, applications should be adding these, and third-party applications should be able to add them. - Code is spread across `Transaction` and `Editor` classes somewhat oddly. For example, generating old/new values would probably make more sense at the `Transaction` level, but it currently exists at the `Editor` level. - Both types of classes have a lot of functions based on `switch()` statements, which require a ton of boilerplate and are just generally kind of hard to work with. This creates classes for each type of transaction, and moves almost all of the logic to them. These classes are simpler and more focused than the old stuff was, and can organize related code better. This starts inching toward defining `CoreTransactions` for features shared across applications. It only defines the "Create" transaction so far, but at some point I plan to move all the other shared transactions to Core and let them control which objects they're available for. Test Plan: - Created pastes with web UI and API. - Edited all paste properites. - Archived/activated. - Verified files got reasonable names. - Reviewed timeline and feed. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9789 Differential Revision: https://secure.phabricator.com/D16111
2016-06-10 01:00:06 +02:00
public function getTitle() {
return pht(
"%s updated the paste's language from %s to %s.",
$this->renderAuthor(),
$this->renderLanguageValue($this->getOldValue()),
$this->renderLanguageValue($this->getNewValue()));
Modularize application transactions in Paste, mostly Summary: Ref T9789. `Transaction` and `Editor` classes are the last major pieces of infrastructure that haven't been fully modularized. Some of the specific issues are: - `Editor` classes rely on a bunch of `instanceof` stuff in the base class to pick up transaction types like "subscribe", "projects", etc. Instead, applications should be adding these, and third-party applications should be able to add them. - Code is spread across `Transaction` and `Editor` classes somewhat oddly. For example, generating old/new values would probably make more sense at the `Transaction` level, but it currently exists at the `Editor` level. - Both types of classes have a lot of functions based on `switch()` statements, which require a ton of boilerplate and are just generally kind of hard to work with. This creates classes for each type of transaction, and moves almost all of the logic to them. These classes are simpler and more focused than the old stuff was, and can organize related code better. This starts inching toward defining `CoreTransactions` for features shared across applications. It only defines the "Create" transaction so far, but at some point I plan to move all the other shared transactions to Core and let them control which objects they're available for. Test Plan: - Created pastes with web UI and API. - Edited all paste properites. - Archived/activated. - Verified files got reasonable names. - Reviewed timeline and feed. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9789 Differential Revision: https://secure.phabricator.com/D16111
2016-06-10 01:00:06 +02:00
}
public function getTitleForFeed() {
return pht(
'%s updated the language for %s from %s to %s.',
Modularize application transactions in Paste, mostly Summary: Ref T9789. `Transaction` and `Editor` classes are the last major pieces of infrastructure that haven't been fully modularized. Some of the specific issues are: - `Editor` classes rely on a bunch of `instanceof` stuff in the base class to pick up transaction types like "subscribe", "projects", etc. Instead, applications should be adding these, and third-party applications should be able to add them. - Code is spread across `Transaction` and `Editor` classes somewhat oddly. For example, generating old/new values would probably make more sense at the `Transaction` level, but it currently exists at the `Editor` level. - Both types of classes have a lot of functions based on `switch()` statements, which require a ton of boilerplate and are just generally kind of hard to work with. This creates classes for each type of transaction, and moves almost all of the logic to them. These classes are simpler and more focused than the old stuff was, and can organize related code better. This starts inching toward defining `CoreTransactions` for features shared across applications. It only defines the "Create" transaction so far, but at some point I plan to move all the other shared transactions to Core and let them control which objects they're available for. Test Plan: - Created pastes with web UI and API. - Edited all paste properites. - Archived/activated. - Verified files got reasonable names. - Reviewed timeline and feed. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9789 Differential Revision: https://secure.phabricator.com/D16111
2016-06-10 01:00:06 +02:00
$this->renderAuthor(),
$this->renderObject(),
$this->renderLanguageValue($this->getOldValue()),
$this->renderLanguageValue($this->getNewValue()));
Modularize application transactions in Paste, mostly Summary: Ref T9789. `Transaction` and `Editor` classes are the last major pieces of infrastructure that haven't been fully modularized. Some of the specific issues are: - `Editor` classes rely on a bunch of `instanceof` stuff in the base class to pick up transaction types like "subscribe", "projects", etc. Instead, applications should be adding these, and third-party applications should be able to add them. - Code is spread across `Transaction` and `Editor` classes somewhat oddly. For example, generating old/new values would probably make more sense at the `Transaction` level, but it currently exists at the `Editor` level. - Both types of classes have a lot of functions based on `switch()` statements, which require a ton of boilerplate and are just generally kind of hard to work with. This creates classes for each type of transaction, and moves almost all of the logic to them. These classes are simpler and more focused than the old stuff was, and can organize related code better. This starts inching toward defining `CoreTransactions` for features shared across applications. It only defines the "Create" transaction so far, but at some point I plan to move all the other shared transactions to Core and let them control which objects they're available for. Test Plan: - Created pastes with web UI and API. - Edited all paste properites. - Archived/activated. - Verified files got reasonable names. - Reviewed timeline and feed. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9789 Differential Revision: https://secure.phabricator.com/D16111
2016-06-10 01:00:06 +02:00
}
}