spficklin
commented
1 year ago Here's an example of the entire obi__orgnaism field. So much easier to understand!!!
<?php
namespace Drupal\tripal_chado\Plugin\Field\FieldType;
use Drupal\tripal_chado\TripalField\ChadoFieldItemBase;
use Drupal\tripal_chado\TripalStorage\ChadoVarCharStoragePropertyType;
use Drupal\tripal_chado\TripalStorage\ChadoIntStoragePropertyType;
use Drupal\tripal\TripalStorage\StoragePropertyValue;
use Drupal\core\Form\FormStateInterface;
use Drupal\core\Field\FieldDefinitionInterface;
/**
* Plugin implementation of Tripal string field type.
*
* @FieldType(
* id = "obi__organism",
* label = @Translation("Chado Organism Reference"),
* description = @Translation("A chado organism reference"),
* default_widget = "obi__organism_widget",
* default_formatter = "obi__organism_formatter"
* )
*/
class obi__organism extends ChadoFieldItemBase {
public static $id = "obi__organism";
/**
* {@inheritdoc}
*/
public static function mainPropertyName() {
return 'label';
}
/**
* {@inheritdoc}
*/
public static function defaultFieldSettings() {
$settings = parent::defaultFieldSettings();
$settings['termIdSpace'] = 'OBI';
$settings['termAccession'] = '0100026';
return $settings;
}
/**
* {@inheritdoc}
*/
public static function defaultStorageSettings() {
$settings = parent::defaultStorageSettings();
return $settings;
}
/**
* {@inheritdoc}
*/
public static function tripalTypes($field_definition) {
$entity_type_id = $field_definition->getTargetEntityTypeId();
// Get the length of the database fields so we don't go over the size limit.
$chado = \Drupal::service('tripal_chado.database');
$schema = $chado->schema();
$organism_def = $schema->getTableDef('organism', ['format' => 'Drupal']);
$cvterm_def = $schema->getTableDef('cvterm', ['format' => 'Drupal']);
$genus_len = $organism_def['fields']['genus']['size'];
$species_len = $organism_def['fields']['species']['size'];
$iftype_len = $cvterm_def['fields']['name']['size'];
$ifname_len = $organism_def['fields']['infraspecific_name']['size'];
$label_len = $genus_len + $species_len + $iftype_len + $ifname_len;
// Get the base table columns needed for this field.
$settings = $field_definition->getSetting('storage_plugin_settings');
$base_table = $settings['base_table'];
$base_schema_def = $schema->getTableDef($base_table, ['format' => 'Drupal']);
$base_pkey_col = $base_schema_def['primary key'];
$base_fk_col = array_keys($base_schema_def['foreign keys']['organism']['columns'])[0];
// Return the properties for this field.
return [
new ChadoIntStoragePropertyType($entity_type_id, self::$id, 'record_id', [
'action' => 'store_id',
'drupal_store' => TRUE,
'chado_table' => $base_table,
'chado_column' => $base_pkey_col
]),
new ChadoIntStoragePropertyType($entity_type_id, self::$id, 'organism_id', [
'action' => 'store',
'chado_table' => $base_table,
'chado_column' => $base_fk_col,
]),
new ChadoVarCharStoragePropertyType($entity_type_id, self::$id, 'label', $label_len, [
'action' => 'replace',
'template' => "<i>[genus] [species]</i> [infraspecific_type] [infraspecific_name]",
]),
new ChadoVarCharStoragePropertyType($entity_type_id, self::$id, 'genus', $genus_len, [
'action' => 'join',
'path' => $base_table . '.organism_id>organism.organism_id',
'chado_column' => 'genus'
]),
new ChadoVarCharStoragePropertyType($entity_type_id, self::$id, 'species', $species_len, [
'action' => 'join',
'path' => $base_table . '.organism_id>organism.organism_id',
'chado_column' => 'species'
]),
new ChadoVarCharStoragePropertyType($entity_type_id, self::$id, 'infraspecific_name', $ifname_len, [
'action' => 'join',
'path' => $base_table . '.organism_id>organism.organism_id',
'chado_column' => 'infraspecific_name',
]),
new ChadoIntStoragePropertyType($entity_type_id, self::$id, 'infraspecific_type', [
'action' => 'join',
'path' => $base_table . '.organism_id>organism.organism_id;organism.type_id>cvterm.cvterm_id',
'chado_column' => 'name',
'as' => 'infraspecific_type_name'
])
];
}
}
laceysanderson
codeclimate[bot]
Overview
This PR addresses Issue #310. Despite that our three complex fields were working the programming of them was a bit confusing. In a design discussion we came up with a way to make things more clear. That design is described in issue #310. However, this PR goes a bit further and makes fields even more clear. Here's what I did.
Property Actions
We had originally decided to rename our property actions for Chado as: store, store_id, store_link_id, store_fixed, join, replace, and function. The store_link_id, and store_fixed were new.
However, I made a few adjustements:
schema__additional_typefield does this.Field Property Settings
Previously, property settings were provided in three different places! This made it difficult to know where a developer should set properties? Previously, some properties would get set during field initialization (such as in the Chado Prepare step), others got set in the field class itself and others were set in parent classes. Now, property setting are only set in the property class itself. This way it's easy for a site developer to know exactly what's beeing set for each property.
Record ID property
Previously, the
TripalFieldItemBaseclass provided to all fields a default property for therecord_id. I removed this. In hindsight, I didn't think we wanted to force all fields, including those not for Chado, to have a built-inrecord_idproperty. I did not move this to theChadoFieldItemBasebecause I decided to let field developers implement it. That way they cand do it how they want. It returns flexibility to the field developer.Also, in the past every field had to have a property with a key named
record_id. This is no longer the case because it didn't make sense to require the action ofstore_idand a key ofrecord_id. We only need to requirestore_idso users are free to give the property a key of whatever they like.Value property
Previously, every field was required to have a property with a key named
value. This make naming properties a bit confusing because all of the properites are given names that correspond to what they store except this property. For example in theobi__organismfield, it must store theorganism_idand that property was given the key ofvalue. But that's confusing becuase it's the property namedlabelthat is shown to the user. I discovered you can tell Drupal what property key can be used for the primary value by returing tke key in the functionmainPropertyName()of the field class. So, if a complex field doesn't have avaluekey, that's okay as long as the user tells Drupal what it should be via themainPropertyName()function. I think this makes creating properties more intuitive as you don't have to cram a key ofvalueonto a property that doen't make sense for it.tripalValuesTemplate()
The
tripalValuesTemplate()function is no longer needed in a field class. It's still required by Tripal but this PR automates creation of the return value. Now, in theTripalFieldItemBasethe function calls thetripalTypes()function and generates a values array that matches. This means that field developers no longer need to write it. This is great because it was too easy to accidientally forget to add a value for every property, or if you changed a key of a property in thetripalTypesfunction it was too easy to forget to also do it in thetripalValuesTemplate()function.Field Properties with CV as keys
Previously, in our complex fields, the keys of properties were CV terms (e.g. schema__label). We did a similar thing in Tripal v3 because it helped web services. But, I thought this made programming fields harder for folks, and there's no reason for this. We can easily add a required term for all properties when they are instantiated. The property key does not need to be that name. You'll notice in all of our complex fields, now, the property keys are more of what is stored by the property, which I think makes it easier to program and more readable. I will create an issue to add a term to properties.
The
defaultTripalTypesanddefaultTripalValuesTemplatefunctions are goneNow that site developers program their own field properties all within their field classes we don't have a need for providing default types. I also found these functions a bit weird because they provide default types implying they could be adjusted but yet they were required. Also, when we did make changes to the
record_idproperty provided by these functions it was confusing as to what was going on (@laceysanderson commented on this). So, once I did all of the cleaning above, these functions weren't used anymore and I took them out. We can put them back if needed.max_delta
This PR does not implement the max delta to keep large numbers of records from being loaded. It was so long/hard to get all of these changes done I didn't feel like doing this minor thing, but we still need it.
Testing
To test this PR, you need to create content that use each of the three complex field types. You must start with a completely fresh install of Tripal.
Type field & Organism field
Prop field