Compatibility with Group Module

Hii @tekNorah

Lot of things to share with you here :) ! I love that !! First Like lot of entities Group have lot of specificities regardless others "standards" but that entity are really correctly generated I see it's so simple to tell Form Mode Manager API what is the Group specificities.

Group / Group Content not work "out of the box" because form handlers aren't standard (add/edit/delete) and common entities have following keys (add_form/edit/delete). It's not really a problems because the abstract level of Form Mode Manager allow you to inform form mode manager abstract factory with a plugin 'EntityRoutingMap' that allow you to build an object (plugin) to make a Bridge with entities routes and entity definition (that not exists in core).

The approach in this article appears to be what I am talking about.

What do you think? Does it make sense to use hook_entity_type_alter? Seems like this would not be done on load of the default form, but rather it changes the settings of particular forms. If so, is there a different hook to use for altering the default form on load of the page?

A large part of response for that is in Spion article and https://youtu.be/iZHsLo0m61c this video to show you how use Form Mode Manager with Form Class associated because Form Mode Manager work for you (enjoy :D)

AGAIN !! I think Form Mode Manager need more extendability think to directly work with Form Mode Manager API with events to make better control before needed tons of evil hooks, I need to think about that and I need really more feedback of developpers (GOD HELP ME :D)

WOOPS ! Here you are the plugin file to make Group compatible :) feel free to add it in your custom module of in Group in future.

This is pretty similar to #2834749: It seems not works with Profile

Hi @tekNorah,

After seen your tests and see group codes I can help you now.

I will give you my opinion on what you are trying to accomplish (make Form Mode Manager and Groups compatible via the Form Mode Manager plugin). To abstract the operations of entities which for each entities of the keys impossible to predict the plugin EntityRoutingMap was made available based on a common denominator between the basic entities and those of the core (node ​​/ media / term etc .. .). the keys that the code looks for within form mode manager are thus ('add_form' / 'edit_form' / 'delete_form') so you can not define a plugin with the keys (add / edit / delete).

Then Group seems to add a higher level of entity workflow (join / leave) and these are group-specific concepts so you have to implement them for Form Mode Manager to process them. I explain further down how to do

First with the attached code I can have

/group_content/add-list/{form_mode_name}
/group/add/{group_type}/{form_mode_name}
/group/{group}/content/add/{plugin_id}/{form_mode_name}
/group/{group}/content/{group_content}/edit/{form_mode_name}

/group/add-list/{form_mode_name}
/group/{group}/edit/{form_mode_name}

routes working correctly. With that I have ability to add/edit group and group_content

We have somes other form actions to Discover like :

entity.group.join
entity.group.leave
entity.group_content.create_page
entity.group_content.create_form
entity.group_content.group_node_add_page

To add that into Form Mode Manager you need to create new even_subscriber like Form Mode Manager (by extends)

  form_mode_manager.route_subscriber:
    class: Drupal\form_mode_manager\Routing\EventSubscriber\FormModesSubscriber
    arguments: ['@entity_type.manager', '@entity_display.repository', '@form_mode.manager', '@plugin.manager.entity_routing_map']
    tags:
      - { name: event_subscriber }

@see/@eg the following code :

  /**
   * Add a collection of route per form mode for current entity.
   *
   * Each entity need to define a collection of routes to be used by Drupal.
   * Each `entity operation` is a form handler present for all,
   * ContentEntityType plugins. Each operation represent a Form to be,
   * displayed by formBuilder service in routes controllers.
   * To respect core logic implemented by Drupal we need to add,
   * a route for each operations (add/edit/add_page/admin_add) dynamically and,
   * a transverse controller compatible to use form modes.
   *
   * Each routes generated by `setFormModeCollection` and,
   * `setAddPageCollection` respect the following naming,
   * `ENTITY_ROUTES_BASIS.FORM_MODE_NAME` eg for Node entity :
   *
   * @code
   *  $routes = [
   *    'add_form' => 'node.add.FORM_MODE_NAME',
   *    'edit_form' => 'entity.node.edit_form.FORM_MODE_NAME',
   *    'add_page' => 'form_mode_manager.node.add_page.FORM_MODE_NAME',
   *    'admin_add' => 'node.add.FORM_MODE_NAME',
   *  ];
   * @endcode
   *
   * @param array $form_modes
   *   All form-modes available for specified entity_type_id.
   */
  protected function addFormModesRoutes(array $form_modes) {
    foreach ($form_modes as $form_mode_infos) {
      $this->setFormModeCollection($form_mode_infos, 'join');
      $this->setFormModeCollection($form_mode_infos, 'leave');
      $this->setFormModeCollection($form_mode_infos, 'create_page');
      $this->setFormModeCollection($form_mode_infos, 'create_form');
      $this->setFormModeCollection($form_mode_infos, 'group_node_add_page');

      if (!empty($this->entityDefinition->getKey('bundle'))) {
        $this->setAddPageCollection($form_mode_infos);
      }
    }
  }

It's a good feature request to try to discover the EntityPluginMap 'operations' key to automatically add each operation available for entity. But that can be dangerous if people don't undestand implication of that ... Flexibility can be a trap sometimes.

Hii again,

I have some information to you about compatibility of Groups + Form Mode Manager. First Groups seem's to implement some custom routes via RouteProvider and define her proper Controllers @see \Drupal\group\Entity\Controller\GroupContentController. Infact Form Mode Manager can work because the concept of Abstract Controller Factory is here to handle compatibility with ALL entities BUT you need to understand and make some additional code to do that.

For definition of routes you need to add some more parameters custom for group and not always exposed by group routes in your custom

To use Controller part uou need to make an extend of \Drupal\form_mode_manager\ComplexEntityFormModes Like \Drupal\form_mode_manager\TaxonomyEntityFormModes to expose how recover all informations in your \Drupal\group_custom_form_mode_manager\Routing\EventSubscriber\FormModesSubscriber

The concept and reason why Form Mode Manager is strongly abstract is that Content Entities can be really complex and unpredictable for Form Mode Manager. To take ability to use Form Modes with Form Mode Manager you need to expose how your entities works and implement your specific parameters with subscriber. After Route definition are good next step are using the Controller Factory provided by Form Mode Manager. This factory is based on similar concept as routes subscriber. Each entity can have some custom requirements and needed unpredictable then Form Mode Manager have identified Two Pattern (Complex entity (with bundle) And Unbundeled entity (without bundle)). In Complex Familly we have some custom example like Media / Taxonomy not unsing 'type' bundle key but more custom (vid || mid) then we have created a specific Object to expose how to make a controller compatible with theses entities. Please see the method Factory responsible of recovering of Correct controller ==> \Drupal\form_mode_manager\Controller\FormModeManagerEntityController::getEntityControllerObject

In your case Groups + Groups content + Form Mode Manager on every place that seem's to be a futur Contributed Module to handle FULL compatibility correctly.

ATM the Group / Group content entity works for simple usecases but for more Group specific usecases without more code that compatibility isn't revelant for Form Mode Manager.

I attach you a draft to show you the way to make this compatibility working. That a really interesting idea to make a new contributor module to be an "Interpreter" of two modules.

Hii @tekNorah,

Sorry for the delay again it's complicated to find time to see groups module code .. That's really not a simple module :D

The join/leave routes appear to be under the group entity, but actually store data under the group_membership group_content type. Does that mean that group_membership is a group_content "bundle"?

No, it's not a group_content bundle but group_membership exist to "Wrap" group_content entities
@see "\Drupal\group\GroupMembershipLoader"

/**
 * Loader for wrapped GroupContent entities using the 'group_membership' plugin.
 *
 * Seeing as this class is part of the main module, we could have easily put its
 * functionality in GroupContentStorage. We chose not to because other modules
 * won't have that power and we should provide them with an example of how to
 * write such a plugin-specific GroupContent loader.
 *
 * Also note that we don't simply return GroupContent entities, but wrapped
 * copies of said entities, namely \Drupal\group\GroupMembership. In a future
 * version we should investigate the feasibility of extending GroupContent
 * entities rather than wrapping them.
 */

I guess, just not sure if I need to create a new event subscriber for the group_membership entity or just add the join/leave actions under the group_content subscriber you have in your example.

&

Also, I get that I need to create an GroupContentEntityFormMode, but, how do I get the main controller to call/use it?

As already seen before, that's not an entity. For GroupContentEntityFormMode Why you need to add custom logic here ? Normally GroupContent are a ContentEntity (complex) and that does works IMHO (with attached sub-mobule join in that issue).
In all cases the FormModeManagerEntityController are an Abstract Factory and then support inherence or adding more Controller type without changing Fmm base code. In futur that would be great to delegate an Event XOR hook to add more controller in switch. To Add your own *EntityFormMode you should follow

1/ Extends \Drupal\form_mode_manager\Controller\FormModeManagerEntityController and overide getEntityControllerObject() method.
2/ Adapt \Drupal\form_mode_manager\Routing\EventSubscriber\FormModesSubscriber if you need to change all fmm routes OR if you use the code join in that issue (or custom EventSubscriber) define \Drupal\form_mode_manager\Routing\EventSubscriber\FormModesSubscriber::FORM_MODE_DEFAULT_CONTROLLER constant to your XxxxEntityController created previously (this controller extends FormModeManagerEntityController and contain your own getEntityControllerObject() method factory.
3/ Add you usecases like

      case 'my_entity_type_id':
        $object = new GroupContentEntityFormMode(
          $this->renderer,
          $this->account,
          $this->formModeManager,
          $this->entityFormBuilder,
          $this->entityRoutingMap,
          $this->formBuilder,
          $this->entityTypeManager
        );

        break;

And Enjoy you can now use your group_content entities with the dynamic controller factory. I admit I don't have more time to change the Factory to build a discovery or plugin to be more dynamic and transparent. This module are the best friend of developper :D

That's help you ?

In attachament the new version of sub module to be compatible with Group content (membership). In future that's would be great this module become a REAL module with fmm dependency and cleanup to take ability to use group content membership with form modes.

@tekNorah : Can you post a small feedback and what works or not works as excepted please ?

If anyone (tekNorah i hope) need to help or become co maintainer of futur bridge module (for maintain usability with group content).

I flag this issue postponed and waiting sub module project to continue the compatibility effort.

H @tekNorah !

Thank you to continue to work on this sub module :) It's now time to this project to have a classique life cycle and to you to become a co maintainer of https://www.drupal.org/project/group_form_mode_manager !! Congratulation :) !!

Now you can continue all dev in that repository and start to correctly describe our project (and you english are very better than me :D).

I go to create a follow-up issue to continue and after we can speak about roadmap and others cool subject arroud FMM + group.