Coder Social home page Coder Social logo

fields_generator's Introduction

Build Status DOI

Tripal Fields Generator

This is a CLI tool to help automate the generation of Tripal fields for use in Tripal 3 development. We highly recommend you read the developer handbook before attempting to use this tool. It supports creating both Tripal and Chado fields.

TFG hearthstone logo

Documentation

Installation

Using Composer

The easiest way to install Tripal Fields Generator is using Composer.

Install command

composer global require "statonlab/fields_generator:~0.1"

Update command

composer global update

Note: make sure you export the composer bin directory by running the following command:

# Add this line to your .bashrc or .bash_profile to persist between shell sessions.
export PATH="$PATH:~/.composer/vendor/bin"

Manual installation

You can download this tool using the "Clone or download" button above or cloning the repository using Git.

git clone https://github.com/statonlab/fields_generator.git

Usage

Generate a new field by running the following command and answering a few questions. By default, Tripal Fields Generator will generate a Chado field, but it can also generate Tripal fields.

# If installed globally with composer
makefield [--output|-o=/full/path/to/module]

# If installed manually without composer
./makefield [--output|-o=/full/path/to/module]

The generator will ask you for both the DB name and the CV name: these names correspond to the chado.db and chado.cv tables. If you aren't sure what these values are, you can use the EBI Ontology lookup Service CVterm entry as a guide: the DB name is the value in the orange box, and the CV name is the value in the teal box. For a full explanation, please read the CV guide.

Alternatively, the below table shows the DB and CV values for commonly used ontologies in Tripal 3.

FULL NAME DB CV
DCMI metadata terms dc dc
Eagle-I Research Ontology ERO ero
EDAM data data EDAM
EDAM format format EDAM
EDAM operation operation EDAM
EDAM topic topic EDAM
Friend of a Friend foaf foaf
Gene ontology biological process GO biological_process
Gene ontology cellular component GO cellular_component
Gene ontology molecular function GO molecular_function
hydra hydra hydra
Information Artifact Ontology IAO IAO
local local local
Ontology for Biomedical Investigation OBI OBI
Ontology for genetic interval OGI ogi
Ontology of Biological and Clinical Statistics OBCS OBCS
Relationship ontology (legacy) RO ro
Resource Description Framework Schema rdfs rdfs
schema schema schema
Semanticscience Integrated Ontology SIO SIO
Sequence ontology SO sequence
Software Ontology SWO swo
Systems Biology SBO sbo
Taxonomic Rank TAXRANK taxonomic_rank

In order for Drupal to recognize your fields, you must...

  • Place the file generated by this tool in the correct location (see below)
  • Specify which bundles your field will attach to. Fields generated by this tool attach to the organism bundle by default.
  • Clear the cache (drush cc all).
  • Add the field in Structure->Tripal_Content

Options

Option default description example
--output (-o) Current working directory The path to the module responsible for the field. makefield -o="/var/www/html/sites/all/modules/my_module"
--type (-t) chado The type of field to generate. Choose between Chado which would extend ChadoField or Tripal to extend TripalField makefield -t=tripal

Output

Tripal Fields Generator will create four files that define your field. For the custom controlled vocabulary (CV) term example defined in the local CV, the field is defined in three files:

  • The Fields class, local__example.inc
  • The field formatter, local__example_formatter.inc
  • The field widget, local__example_widget.inc

Additionally, a fields file stub describing the fields declared in your module is generated: for this example module, the file might be tripal_example_module.fields.inc. Note that all of the fields in your module are described here: running Tripal Fields Generator multiple times will require you to combine this file for each field. The final structure of your fields should look like the example below, with a given field CV__CVTERM in module/includes/TripalFields/CV_CVterm, and the module.fields.inc located in module/includes. For a full example of a field please visit the Tripal Example Module repository by @laceysanderson.

Output file structure

By default, the module-level field file (moduleName.fields.inc) will be placed in CV__CVterm_output, and the classes defining your field will be in the field folder CV__CVterm_output/CV__CVterm. Note that the value of CV corresponds to what you enter for the DB, not the CV table!

CV__CVterm_output/
├── CV__CVterm/
│   ├── CV__CVterm.inc
│   ├── CV__CVterm_formatter.inc
│   └── CV__CVterm_widget.inc  
└── module.fields.inc

You will need to move these files to conform to the pattern in the previous section. Alternatively, you may specify a different output path using the output flag, -o="/path/to/module" or --output="/path/to/module". This will automatically define your fields in the correct place. In either case, your final module field structure should look like the example below.

module/
├── includes/
│   ├── TripalFields/
│   │   └── CV__CVterm/
│   │       ├── CV__CVterm.inc
│   │       ├── CV__CVterm_formatter.inc
│   │       └── CV__CVterm_widget.inc
│   └── module.fields.inc
└── rest of my module...

Terms

The below terms must be provided for each field you generate.

  • Field Label: A human readable label for the field. e,g. Germplasm Summary
  • Field Description: A human readable description of the field
  • Module Name: The machine name of the module this field is distributed with. e,g. tripal_germplasm_module
  • Database name:
  • CV name:
  • Controlled Vocabulary Term: The term name. e,g. germplasm_summary
  • Accession: The accession number for this term in the vocabulary, e,g. 30021. This must match the dbxref value in Chado. Biological CVs will always use numeric CVterms. Semantic CVs will generally use strings.

Examples

Contributing

Contributions are highly welcomed and recommended.

  • Fork the repository.
  • Create a branch that contains your code.
  • Create a pull request with a clear description of your contribution for us to review.

License

This tool is licensed under GNU GPLv2. Copyright 2017 University of Tennessee. All rights reserved.

The Tripal Fields Generator "logo" is derived from the collectible card game Hearthstone, copyright © Blizzard Entertainment, Inc. Hearthstone® is a registered trademark of Blizzard Entertainment, Inc. Tripal Fields Generator is not affiliated or associated with or endorsed by Hearthstone® or Blizzard Entertainment, Inc.

fields_generator's People

Contributors

almasaeed2010 avatar bradfordcondon avatar laceysanderson avatar noah-77 avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

Forkers

almasaeed2010

fields_generator's Issues

simpler rule for CV vs DB?

Use the EBI breadcrumb.

so teal box = CV, orange box = DB. IF obo namespace is provided in the sidebar, that will override the CV

This works for all DB/CVs except where capitalization is inconsistent between db and cv.

h for help?

Right now the questions we ask the user to generate the field are too verbose making it not clear where the cursor is which is a bit disorienting (for me at least). For a better experience, I suggest adding the following:

  • A -v option to enable verbose mode which is the mode it is currently using
  • Typing h or help as the answer to any question should generate help text

Yes it's a little bit of work but a good improvement imo.

improving CVterm suggestions

since OLS tends to show you lots of garbage from garbage CVs...

Elasticsearch integration

  • Pick which CVs to search?

broken build

phpunit
PHP Fatal error:  Declaration of GeneratorEngineTest::setUp() must be compatible with PHPUnit\Framework\TestCase::setUp(): void in /home/travis/build/tripal/fields_generator/tests/Generator.php.test on line 34
PHP Stack trace:
PHP   1. {main}() /home/travis/.phpenv/versions/7.2.15/bin/phpunit:0
PHP   2. PHPUnit\TextUI\Command::main() /home/travis/.phpenv/versions/7.2.15/bin/phpunit:619
PHP   3. PHPUnit\TextUI\Command->run() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/TextUI/Command.php:164
PHP   4. PHPUnit\TextUI\Command->handleArguments() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/TextUI/Command.php:175
PHP   5. PHPUnit\Util\Configuration->getTestSuiteConfiguration() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/TextUI/Command.php:910
PHP   6. PHPUnit\Util\Configuration->getTestSuite() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Util/Configuration.php:870
PHP   7. PHPUnit\Framework\TestSuite->addTestFiles() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Util/Configuration.php:1013
PHP   8. PHPUnit\Framework\TestSuite->addTestFile() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Framework/TestSuite.php:625
PHP   9. PHPUnit\Util\FileLoader::checkAndLoad() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Framework/TestSuite.php:546
PHP  10. PHPUnit\Util\FileLoader::load() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Util/FileLoader.php:47
Fatal error: Declaration of GeneratorEngineTest::setUp() must be compatible with PHPUnit\Framework\TestCase::setUp(): void in /home/travis/build/tripal/fields_generator/tests/Generator.php.test on line 34
Call Stack:
    0.0008     561248   1. {main}() /home/travis/.phpenv/versions/7.2.15/bin/phpunit:0
    0.0721    9831616   2. PHPUnit\TextUI\Command::main() /home/travis/.phpenv/versions/7.2.15/bin/phpunit:619
    0.0721    9840408   3. PHPUnit\TextUI\Command->run() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/TextUI/Command.php:164
    0.0721    9840408   4. PHPUnit\TextUI\Command->handleArguments() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/TextUI/Command.php:175
    0.0793    9843040   5. PHPUnit\Util\Configuration->getTestSuiteConfiguration() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/TextUI/Command.php:910
    0.0793    9843624   6. PHPUnit\Util\Configuration->getTestSuite() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Util/Configuration.php:870
    0.0798    9881960   7. PHPUnit\Framework\TestSuite->addTestFiles() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Util/Configuration.php:1013
    0.0798    9881960   8. PHPUnit\Framework\TestSuite->addTestFile() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Framework/TestSuite.php:625
    0.0798    9881960   9. PHPUnit\Util\FileLoader::checkAndLoad() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Framework/TestSuite.php:546
    0.0799    9882248  10. PHPUnit\Util\FileLoader::load() phar:///home/travis/.phpenv/versions/7.2.15/bin/phpunit/phpunit/Util/FileLoader.php:47
The command "phpunit" exited with 255.

https://travis-ci.org/tripal/fields_generator/builds/500085780?utm_medium=notification&utm_source=email

typo in stub file generated

$field_name = 'obi__microarray platform'; instead of $field_name = 'obi__microarray_platform';

More accurately, it could automtically introduce white space for machine names, or throw a warning

Changes to the TripalField class

I have just made a change to the TripalField class (on the collections branch of Tripal) which moves the download_formatters out of the $default_instance_settings variable and into it's own static variable. This is because it would be really hard to add new formatters to a field without manually rewritting the settings for existing fields.... too much effort. Once the 'collections' branch gets merged into the 7.x-3.x branch then this change will be active.

Zenodo DOI release

I've added DOI integration via Zenodo. Let's make sure the next release is descriptive.

move static overrides int othe constructor?

I'm not a big fan of our stubs returning the super verbose public $static everything with the comments etc.

I was messing around with extending an importer and took this approach: overriding the parent static methods in the __construct method:

  /**
   * how we previously set it.  no longer necessary, you get style complaints.
   */
  public static $methods = array(
    'file_upload' => FALSE,
    'file_local' => FALSE,
    'file_remote' => FALSE,
  );
  public static $file_required = FALSE;

  /**
   * EutilsImporter constructor.
   *
   * @param \TripalJob|null $job
   */
  public function __construct(TripalJob $job = NULL) {
    parent::__construct($job);
    static::$name = 'NCBI EUtils Accession loader';
    static::$machine_name = 'eutils_loader';
    static::$description = 'Import a BLAST XML file into Chado';
    static::$use_analysis = FALSE;
    static::$button_text = 'Import NCBI Record';
    static::$methods = [
      'file_upload' => FALSE,
      'file_local' => FALSE,
      'file_remote' => FALSE,
    ];
  }

Do we like this more? You get a lot of less code sniffer complaints this way and its a lot more compact.

I also think it will partially resolve #46

library contributed fields need to have "tripal_chado"

for library, the module should be 'tripal_chado'. That's because we dont have the fields.inc file that tells drupal about our field, so someone has to tell drupal about it: and we want that to be Tripal.

To fix, change the 'module' prompt to advise people of this.

Update stubs

Stephen has added more functionality to fields.

I need to update the stub files to reflect this.

style incompatibility

The drupal code sniffer reformats the static variable documentation and its kind of not good.

  • can we use @see like we do for the method definitions?
  • if not, what should we do?
    • remove the comments and perhaps put @see at the top of the class?
    • reformat the comments to follow the Drupal style standard?

add @see to stubs

for the formatter view for example: * @see TripalFieldFormatter::view()

I like having the stubs generated have the full text, but maybe we should do something like:

/**
* @see TripalFieldFormatter::view()
* the full description for this method is provided below.  You should delete it, and only leave the @see annotation above, when you are ready to contribute your code.
* full 
* description...
**/

We need help text

I think migrating to symfony console would be great for this module. It'll make the command much more intuitive to use.

Move term adding function to the install

We currently generate the term insertion code in the .fields.inc file but the badges guideline specifically asks for this to be in the install file. Would a simple comment suffice? Or do we need to create a new file for it?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.