2014-10-17 14:01:57 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
abstract class AlmanacController
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
extends PhabricatorController {
|
|
|
|
|
2014-11-06 00:28:36 +01:00
|
|
|
protected function buildAlmanacPropertiesTable(
|
|
|
|
AlmanacPropertyInterface $object) {
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
|
|
|
|
$viewer = $this->getViewer();
|
2014-11-06 00:28:36 +01:00
|
|
|
$properties = $object->getAlmanacProperties();
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
|
2014-12-17 20:10:50 +01:00
|
|
|
$this->requireResource('almanac-css');
|
|
|
|
|
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$object,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
|
|
|
|
|
|
|
$field_list = PhabricatorCustomField::getObjectFields(
|
|
|
|
$object,
|
|
|
|
PhabricatorCustomField::ROLE_DEFAULT);
|
|
|
|
|
|
|
|
// Before reading values from the object, read defaults.
|
|
|
|
$defaults = mpull(
|
|
|
|
$field_list->getFields(),
|
|
|
|
'getValueForStorage',
|
|
|
|
'getFieldKey');
|
|
|
|
|
|
|
|
$field_list
|
|
|
|
->setViewer($viewer)
|
|
|
|
->readFieldsFromStorage($object);
|
|
|
|
|
|
|
|
Javelin::initBehavior('phabricator-tooltips', array());
|
|
|
|
|
|
|
|
$icon_builtin = id(new PHUIIconView())
|
2016-01-28 05:38:01 +01:00
|
|
|
->setIcon('fa-circle')
|
2014-12-17 20:10:50 +01:00
|
|
|
->addSigil('has-tooltip')
|
|
|
|
->setMetadata(
|
|
|
|
array(
|
|
|
|
'tip' => pht('Builtin Property'),
|
|
|
|
'align' => 'E',
|
|
|
|
));
|
|
|
|
|
|
|
|
$icon_custom = id(new PHUIIconView())
|
2016-01-28 05:38:01 +01:00
|
|
|
->setIcon('fa-circle-o grey')
|
2014-12-17 20:10:50 +01:00
|
|
|
->addSigil('has-tooltip')
|
|
|
|
->setMetadata(
|
|
|
|
array(
|
|
|
|
'tip' => pht('Custom Property'),
|
|
|
|
'align' => 'E',
|
|
|
|
));
|
|
|
|
|
|
|
|
$builtins = $object->getAlmanacPropertyFieldSpecifications();
|
|
|
|
|
|
|
|
// Sort fields so builtin fields appear first, then fields are ordered
|
|
|
|
// alphabetically.
|
|
|
|
$fields = $field_list->getFields();
|
|
|
|
$fields = msort($fields, 'getFieldKey');
|
|
|
|
|
|
|
|
$head = array();
|
|
|
|
$tail = array();
|
|
|
|
foreach ($fields as $field) {
|
|
|
|
$key = $field->getFieldKey();
|
|
|
|
if (isset($builtins[$key])) {
|
|
|
|
$head[$key] = $field;
|
|
|
|
} else {
|
|
|
|
$tail[$key] = $field;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$fields = $head + $tail;
|
|
|
|
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
$rows = array();
|
2014-12-17 20:10:50 +01:00
|
|
|
foreach ($fields as $key => $field) {
|
|
|
|
$value = $field->getValueForStorage();
|
|
|
|
|
|
|
|
$is_builtin = isset($builtins[$key]);
|
|
|
|
|
|
|
|
$delete_uri = $this->getApplicationURI('property/delete/');
|
|
|
|
$delete_uri = id(new PhutilURI($delete_uri))
|
|
|
|
->setQueryParams(
|
|
|
|
array(
|
|
|
|
'objectPHID' => $object->getPHID(),
|
|
|
|
'key' => $key,
|
|
|
|
));
|
|
|
|
|
|
|
|
$edit_uri = $this->getApplicationURI('property/edit/');
|
|
|
|
$edit_uri = id(new PhutilURI($edit_uri))
|
|
|
|
->setQueryParams(
|
|
|
|
array(
|
|
|
|
'objectPHID' => $object->getPHID(),
|
|
|
|
'key' => $key,
|
|
|
|
));
|
|
|
|
|
|
|
|
$delete = javelin_tag(
|
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'class' => ($can_edit
|
|
|
|
? 'button grey small'
|
|
|
|
: 'button grey small disabled'),
|
|
|
|
'sigil' => 'workflow',
|
|
|
|
'href' => $delete_uri,
|
|
|
|
),
|
|
|
|
$is_builtin ? pht('Reset') : pht('Delete'));
|
|
|
|
|
|
|
|
$default = idx($defaults, $key);
|
|
|
|
$is_default = ($default !== null && $default === $value);
|
|
|
|
|
|
|
|
$display_value = PhabricatorConfigJSON::prettyPrintJSON($value);
|
|
|
|
if ($is_default) {
|
|
|
|
$display_value = phutil_tag(
|
|
|
|
'span',
|
|
|
|
array(
|
|
|
|
'class' => 'almanac-default-property-value',
|
|
|
|
),
|
|
|
|
$display_value);
|
|
|
|
}
|
|
|
|
|
|
|
|
$display_key = $key;
|
|
|
|
if ($can_edit) {
|
|
|
|
$display_key = javelin_tag(
|
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'href' => $edit_uri,
|
|
|
|
'sigil' => 'workflow',
|
|
|
|
),
|
|
|
|
$display_key);
|
|
|
|
}
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
|
|
|
|
$rows[] = array(
|
2014-12-17 20:10:50 +01:00
|
|
|
($is_builtin ? $icon_builtin : $icon_custom),
|
|
|
|
$display_key,
|
|
|
|
$display_value,
|
|
|
|
$delete,
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
$table = id(new AphrontTableView($rows))
|
|
|
|
->setNoDataString(pht('No properties.'))
|
|
|
|
->setHeaders(
|
|
|
|
array(
|
2014-12-17 20:10:50 +01:00
|
|
|
null,
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
pht('Name'),
|
|
|
|
pht('Value'),
|
2014-12-17 20:10:50 +01:00
|
|
|
null,
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
))
|
|
|
|
->setColumnClasses(
|
|
|
|
array(
|
2014-12-17 20:10:50 +01:00
|
|
|
null,
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
null,
|
|
|
|
'wide',
|
2014-12-17 20:10:50 +01:00
|
|
|
'action',
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
));
|
|
|
|
|
|
|
|
$phid = $object->getPHID();
|
|
|
|
$add_uri = $this->getApplicationURI("property/edit/?objectPHID={$phid}");
|
|
|
|
|
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$object,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
|
|
|
|
|
|
|
$add_button = id(new PHUIButtonView())
|
|
|
|
->setTag('a')
|
|
|
|
->setHref($add_uri)
|
|
|
|
->setWorkflow(true)
|
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setText(pht('Add Property'))
|
2016-01-28 05:38:01 +01:00
|
|
|
->setIcon('fa-plus');
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
|
|
|
->setHeader(pht('Properties'))
|
|
|
|
->addActionLink($add_button);
|
|
|
|
|
|
|
|
return id(new PHUIObjectBoxView())
|
|
|
|
->setHeader($header)
|
[Redesign] Add Table, Collapse support to ObjectBox
Summary: Converts most all tables to be directly set via `setTable` to an ObjectBox. I think this path is more flexible design wise, as we can change the box based on children, and not just CSS. We also already do this with PropertyList, Forms, ObjectList, and Header. `setCollapsed` is added to ObjectBox to all children objects to bleed to the edges (like diffs).
Test Plan: I did a grep of `appendChild($table)` as well as searches for `PHUIObjectBoxView`, also with manual opening of hundreds of files. I'm sure I missed 5-8 places. If you just appendChild($table) nothing breaks, it just looks a little funny.
Reviewers: epriestley, btrahan
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D12955
2015-05-20 21:43:34 +02:00
|
|
|
->setTable($table);
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
}
|
|
|
|
|
2014-12-18 23:31:36 +01:00
|
|
|
protected function addLockMessage(PHUIObjectBoxView $box, $message) {
|
|
|
|
$doc_link = phutil_tag(
|
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'href' => PhabricatorEnv::getDoclink('Almanac User Guide'),
|
|
|
|
'target' => '_blank',
|
|
|
|
),
|
|
|
|
pht('Learn More'));
|
|
|
|
|
2015-03-01 23:45:56 +01:00
|
|
|
$error_view = id(new PHUIInfoView())
|
|
|
|
->setSeverity(PHUIInfoView::SEVERITY_WARNING)
|
2014-12-18 23:31:36 +01:00
|
|
|
->setErrors(
|
|
|
|
array(
|
|
|
|
array($message, ' ', $doc_link),
|
|
|
|
));
|
|
|
|
|
2015-03-07 02:03:18 +01:00
|
|
|
$box->setInfoView($error_view);
|
2014-12-18 23:31:36 +01:00
|
|
|
}
|
|
|
|
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
}
|