1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-25 00:02:41 +01:00
phorge-phorge/src/applications/people/customfield/PhabricatorUserRealNameField.php

69 lines
1.6 KiB
PHP
Raw Normal View History

<?php
final class PhabricatorUserRealNameField
extends PhabricatorUserCustomField {
private $value;
public function getFieldKey() {
return 'user:realname';
}
public function getFieldName() {
return pht('Real Name');
}
public function getFieldDescription() {
return pht('Stores the real name of the user, like "Abraham Lincoln".');
}
public function canDisableField() {
return false;
}
public function shouldAppearInApplicationTransactions() {
return true;
}
public function shouldAppearInEditView() {
return true;
}
public function readValueFromObject(PhabricatorCustomFieldInterface $object) {
$this->value = $object->getRealName();
}
public function getOldValueForApplicationTransactions() {
return $this->getObject()->getRealName();
}
public function getNewValueForApplicationTransactions() {
if (!$this->isEditable()) {
return $this->getObject()->getRealName();
}
return $this->value;
}
public function applyApplicationTransactionInternalEffects(
PhabricatorApplicationTransaction $xaction) {
$this->getObject()->setRealName($xaction->getNewValue());
}
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
public function readValueFromRequest(AphrontRequest $request) {
$this->value = $request->getStr($this->getFieldKey());
}
public function renderEditControl(array $handles) {
return id(new AphrontFormTextControl())
->setName($this->getFieldKey())
->setValue($this->value)
->setLabel($this->getFieldName())
->setDisabled(!$this->isEditable());
}
private function isEditable() {
return PhabricatorEnv::getEnvConfig('account.editable');
}
}