Download the PHP package amcgowanca/discoverable_entity_bundle_classes without Composer

On this page you can find all versions of the php package amcgowanca/discoverable_entity_bundle_classes. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of amcgowanca/discoverable_entity_bundle_classes

Informations about the package discoverable_entity_bundle_classes

Discoverable Entity Bundle Classes

Currently in Drupal 8, there is no mechanism for deriving a base entity type's class implementation with a unique class type on a per-bundle basis. As a result, if overriding the entity type class, that class type will be used for all instances in which that entity is instantiated as.

This module is also referred to as "DEBC", short for "Discoverable Entity Bundle Classes".

Installation & usage

Installation via Composer

This module should be installed through use of Composer.

Usage

Discoverable Entity Bundle Classes module does not provide any "out of the box" ready setup or configuration and is focused on enhancing the developer experience of building elegant solutions. As a result, the following is required:

  1. Ensure that the entity storage class for the entity type which you would like entity bundle classes made available for implements the trait Drupal\discoverable_entity_bundle_classes\Storage\SqlContentEntityStorageTrait. This trait's implementation is focused on ensuring that the needed SqlContentEntityStorage class methods from Drupal core are effectively overridden to allow for discoverable bundle classes and their instantiation.

    Note that this module provides the required Storage class representations for Drupal core's Node, Comment and Taxonomy term entities but does not activate them. This is purposefully left for the technical architect of the implementing project to decide. See #2 below.

  2. If the entity type (e.g. Node) is being provided via a Drupal core or contributed module package, ensure that a storage class exists or is made available that implements the required SqlContentEntityStorageTrait trait. Override the entity type's storage class through use of hook_entity_type_alter(&$entity_types).

  3. Define custom entity bundle classes (e.g. Article) which extends the previously defined base entity class. For example, if Article is a type of Node, then it should be defined as:

  4. Any bundle specific class must also implement the interface, ContentEntityBundleInterface.

  5. The bundle specific class must also be annotated with @ContentEntityBundleClass which defines the following properties:

    • label: Human-readable representation of the entity bundle class (e.g. @Translation("Article"))
    • entity_type: The base entity type (e.g. node).
    • bundle: The entity bundle that this class should be applied to.
  6. Finally, clear cache (drush @site.alias cache-rebuild) and begin creating awesome Drupal solutions.

History of this project

The beginning

This module and architectural approach was originally conceived for a global brand. The intent was to allow for a simple proof of concept that enables the ability to derive entity classes (e.g. \Drupal\node\Entity\Node) for specialized implementations. The goal was to allow for a layer of abstraction and decoupling of common Drupal-isms to implement a services and other data managers to act purely on defined interfaces instead of Drupal's data representation.

Fast-forward +1 year

This module has been utilized on regular basis for small non-profit organizations through to Fortune 100s by enabling delivery teams to build elegant software that is removed from the tightly coupled behaviors of common Drupal implementations.

On Drupal.org

Below are links to Drupal.org issues which reference this particular project and/or that this project addresses as part of its architecture.

Real-life example(s)

Its is not uncommon, in fact, it is very common to have projects be overwhelmed with Drupal-isms that appear easy-to-manage early on within a project's development cycle but become very unmanageable as time goes on - let alone after its first production release.

Making multiple data-points "Locationable"

The scenario: A single project has multiple data types - a Node type and Vocabulary, that represented a singular "Location". Due to the duplicative nature, the Vocabulary's implementation existed from the original delivery team and was simply used for the purpose of categorization content. The Node type "Location" was an after thought and therefore was implemented for the purpose of:

The problem: How do I sustain the large codebase without introducing large levels of effort to introduce or eventually remove the data types while persisting functional business logic.

The answer: Through a well abstraction between data types (e.g. a Node or Vocabulary) and services or other class implementations that make use of strongly-typed parameters.

The observed changes: With minimal refactoring of core business logic and class implementations, this particular project was able to reduce the number of Drupal-isms by leveraging DEBC and well-defined interfaces that were implemented by entity bundle classes.

An example of code reduction and type-hinted values, allowed for:

Before:

After:

License

This Drupal module is licensed under the GNU General Public License version 2.

All versions of discoverable_entity_bundle_classes with dependencies

PHP Build Version
Package Version
Requires amcgowanca/entity_utilities Version dev-8.x-1.x
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package amcgowanca/discoverable_entity_bundle_classes contains the following files

Loading the files please wait ....