Needs examples and more thorough documentation

Created on 18 November 2023, 12 months ago
Updated 16 July 2024, 4 months ago

Love the concept and UI is easy to configure! Kudos for creating this.

Some examples and/or better documentation would help a lot though, when trying to extend the transformations with your own.

💬 Support request
Status

Active

Version

1.0

Component

Documentation

Created by

🇫🇮Finland irowboat

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @irowboat
  • 🇩🇰Denmark LupusGr3y

    Yes, the documentation still needs some work. I'll be training some colleagues in the coming month so hopefully that will give some insights into what is confusing for new developers.

    How are you trying to extend the transformations? Altering an existing transformation, a new transformer or a new transformation type?

  • 🇫🇮Finland irowboat

    My goal was using Commerce, and noticed adding variation data to (json) product data wasn't configurable through the UI.

    Configuration fields (such as Commerce's variations, their price fields etc.) apparently generally aren't visible to/configurable with Transform API (UI), as the basic entity config data is hardcoded. It would add a lot of flexibility (in some cases) if 'Manage display' and 'Manage transform' would show similar fields. Probably too much of a rewrite to ask, but at least worth mentioning.

    As for the scenario mentioned, it seems that my options would (at least) be altering the product transform or creating a custom block to include variation data and appending that to products.

    If you can elaborate on ways to go about it, it would definitely save some time.

    Once again thanks!

  • 🇩🇰Denmark LupusGr3y

    I don't know exactly what Commerce is using here, but Transform API does currently need something similar to "Links" and "Moderation Control" display options from core. However even if that is what Commerce is doing then a plugin for Transform API still needs to be implemented.

    Same goes for any extra field types from modules out there, it will show up on "Manage Transforms", but without a Transformer plugin, you can't utilize it. Hopefully the community can help expand the field types and other displays Transform API can support with time.

    For now I'd advice using hook_transform_entity_alter to intercept the transformation of the product and add the transforms that way.

  • 🇮🇳India lipinponmala007

    I made a try on the custom route creation . It worked but thought like there could be a better way

    But for those who are not getting anywhere in exposing your data in a custom non entity route

    /** Example for creating a taxonomy list  reponse **/
    
    
    

    So tried below
    modules/custom/ot_transform/ot_transform.routing.yml

    ot_transform.vocabularyListPage:
      path: 'vocabulary-list'
      defaults:
        _title: 'Vocabulary list'
        _controller: '\Drupal\ot_transform\Controller\OtTransformVocabularyListPage::content'
      requirements:
        _permission: 'access content'
    

    modules/custom/ot_transform/src/Controller/OtTransformVocabularyListPage.php

    
    namespace Drupal\ot_transform\Controller;
    
    use Drupal\Core\Controller\ControllerBase;
    use Symfony\Component\HttpFoundation\Request;
    
    /**
     * Returns responses for OT Transform routes.
     */
    final class OtTransformVocabularyListPage extends ControllerBase {
    
      /**
       * Controller content callback.
       *
       * @param \Symfony\Component\HttpFoundation\Request $request
       *   The request.
       *
       * @return array|\Symfony\Component\HttpFoundation\JsonResponse
       *   The render array or JSON response.
       */
      public function content(Request $request) {
        // Your normal content without ?format=json.
        $content = [
          '#markup' => $this->t('This is vocabulary page!'),
        ];
        // Return the normal content.
        return $content;
      }
    
    }
    
    
    namespace Drupal\ot_transform\Plugin\Transform\Route;
    
    use Drupal\Component\Plugin\PluginInspectionInterface;
    use Drupal\Component\Plugin\DerivativeInspectionInterface;
    use Drupal\transform_api\RouteTransformInterface;
    use Drupal\transform_api\Transform\TransformInterface;
    use Drupal\transform_api\Transform\EntityTransform;
    
    /**
     * Provides a description of your custom route transform plugin.
     *
     * @RouteTransform(
     *   id = "ot_transform.vocabularyListPage",
     *   title = @Translation("OT transform Vocabulary List"),
     * )
     */
    class OtTransformVocabularyListPage implements RouteTransformInterface, PluginInspectionInterface, DerivativeInspectionInterface {
      /**
       * Transform a transform of this type into JSON.
       *
       * @param \Drupal\transform_api\TransformInterface $transform
       *   The transform to transform.
       *
       * @return array
       *   Transformed JSON array.
       */
      public function transform(TransformInterface $transform): array {
        $terms = [];
    
        $name = \Drupal::request()->get('vocabulary');
        if ($name) {
          /** @var \Drupal\taxonomy\Entity\Term[] $terms */
          $termList = \Drupal::entityTypeManager()->getStorage('taxonomy_term')->loadByProperties(['vid' => $name]);
          foreach ($termList as $term) {
            $terms[] = $term->id();
          }
        }
        $transformation = [
            "type" => "entity",
            "field_section" => [
              'field_section_type' => 'field_vocabulary',
              "field_vocabulary" => new EntityTransform('taxonomy_term', $terms, 'default')
            ]
          ];
        return $transformation;
      }
    
      /**
       * {@inheritdoc}
       */
      public function getPluginId() {
        return $this->pluginId;
      }
    
      /**
       * {@inheritdoc}
       */
      public function getPluginDefinition() {
        return [];
      }
    
      /**
       * {@inheritdoc}
       */
      public function getBaseId() {
        return $this->pluginDefinition['base_id'];
      }
    
      /**
       * {@inheritdoc}
       */
      public function getDerivativeId() {
        return $this->pluginDefinition['derivative_id'];
      }
    
    }
    
  • 🇩🇰Denmark LupusGr3y

    Is this trying to replicate the terms list usually done through views?

    If that's the case, then yes, this is probably the way to do it currently, you could even get it to replace the current view for HTML. I figure we could make plugins for views that allow it to handle transforms as well. Although my Views knowledge is very limited.

    Also EntityTransform has some shortcut static functions if you already have the entities.

  • 🇩🇰Denmark LupusGr3y

    @irowboat

    An uodate for the module now allows configuration of base fields that are allowed on view modes to also be configurable on transform modes, does this solve your Commerce issue?

  • 🇮🇳India lipinponmala007

    @LupusGr3y

    What I mean to do is how a non entity router output can be transformed. in above, I am trying to get all the terms based on vocabulary_machine_name need as transformed array. This could be applied to if you are exposing any custom data as well suing the simple transform in the transfrom(). this works but i thought there is some other method which i could not figure it out yet.

  • 🇩🇰Denmark LupusGr3y

    @lipinponmala007

    No, that is currently the only way to transform non-entity routes, at least existing routes. Of course if your make your own routes you could just get the Transformer service and output the JSON via a custom controller directly, but those are currently the options.

  • 🇫🇮Finland irowboat

    @LupusGr3y

    I went another route so can't confirm this at the moment, but good to hear.

    On a sidenote, I still think this module has enormous potential.

    I'm currently building a POC testing a setup where a lightweight JS (Sveltekit but that's irrelevant) app directs requests to Drupal and renders the Transform API-created JSON if the Drupal path exists. I'm not doing extra requests to Drupal for now, so it made sense to change the caching to user based (by adding user to cacheContexts in TransformationCache.php).

    If this works, it's practically just replacing Drupal's theme layer with something less painful, sidestepping most headaches decoupling usually brings. I don't even need to worry about auth syncing with the frontend! Still to solve some issues like form submits and media paths though.

    Also hoping the Views integration works well, since it definitely simplifies things.

Production build 0.71.5 2024