Issues: https://www.drupal.org/project/issues/search/entity_browser?project_issu...

Basic structure

Components

  • Entity browser: Config entity that stores entire configuration for a given EB instance, provides communication interface to other systems, implemets any business logic and glues all pieces of the system together.
  • Browser display: Plugins that bring EB into different contexts in UI: entity_embed uses modal implementation; a field widget could use EB in an iFrame; a system that pushes content to 3rd party systems could use a standalone form to select entities that need to be pushed over; ...
  • Browser widget: Plugins that provide different ways of selecting content (views, custom form, entity form, uploader, field widgets, ...).
  • Widget selector: Plugins that define how different widgets are displayed and selected. Can be tabs, dropdown, buttons, ...
  • Selection display: Plugin that handles display and logic around currently selected entities (before they are actually sent over). Can be something as a grid of rendered entities that were selected - allows user to go into different widgets and select entities in multiple steps or something very simple that pushes entities over as soon as something is selected on one of the widgets.

Basic flows

Initial form load

External system requests a specific EB. EB config entity works with all plugins and delivers a form/selection interface.

Selection of entities when using simple (single step) selection display

User selects entities on one of the widgets. SelectionDisplay plugin relizes that we're not doing any further steps which results in EB emmiting an event with all selected entities attached. It is then up to subscribers to decide what to do with them and where to go from there.

Selection of entities when using "multi step" selection display

Very similar to single step selection. The only difference are multple steps that we can take to select entities. On every step we add selected entities to selection display, which renders them as a grid, table, list, ... Along with that we provide another UI element that ends the selection process. From here on we have same flow as with single step: selection display realizes that we've reached the final step, which results in EB emmiting an event.

Browser widget examples

Tabs display

Dropdown display

Buttons display

Specially useful if we have small number of browser widgets (2 or 3).

Selection display examples

Note: "Simple" (single step) selection display is not includded. However, all examples in previous section can be understood as such.

Grid selection display

Table selection display

Unordered list selection display

Diagrams and wireframes in other formats

ODG version: https://box.zabica.org/public.php?service=files&t=4ccf1e062ad26cde37f308...
PDF version: https://box.zabica.org/public.php?service=files&t=7a734038ecdbf7d8dc8abf...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

slashrsm’s picture

Issue summary: View changes
slashrsm’s picture

This is the basic architecture that me and @marcingy figured out at the whiteborad. It is very simple and very flexible (which allows us to cover lots of different use-cases).

slashrsm’s picture

Issue summary: View changes
FileSize
47.47 KB
31.5 KB
31.8 KB
33.65 KB
27.46 KB
27.81 KB
24.32 KB
slashrsm’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
slashrsm’s picture

Dave Reid’s picture

Hrm, I'm not sure about needing the Browser display plugins. Does this cause more complexity by requiring different methods? Or could we assume both a field widget and an independent FAPI element would be using the modal?

slashrsm’s picture

I think that entity_browser needs to be able to work in any circumstance where entities are being selected (can definitely see cases where something else than modal is better).

Also, if we plan to implement at least 2 or 3 different plugins for every subsystem of entity_browser we ensure that we design interfaces between this subsystems that work in general and are not tied to a specific use case.

kmoll’s picture

I think it would be beneficial to support as many use cases as possible and have a flexible, pluggable architecture. I think it will ultimately lead to more complexity, which I don't like, but I am hoping it will turn out to be less complex than my initial thoughts.

I have a question about where the browser display plugin would fit into the flow. The rest of the components all fit into the flow after an entity browser has been called or invoked. So the main EntityBrowser component would easily control the other plugins. The display browser component would fit into the mix before the EB is invoked. It would really only affect how the link (or any other method of invoking the EB) would behave within the UI context. To me, it we would need either plugins or widgets to invoke the entity browser which would then kick off the initial load flow that you have above and control the rest of the components.

I think I would need to understand what you had in mind for the other use cases in order to get a better picture of how and where the display component would fit it.

slashrsm’s picture

Issue summary: View changes
FileSize
211.71 KB
67.94 KB
slashrsm’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.