- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add bundle classes generator #4903
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
function drush_empty_module_entity_bundle_info_alter(array &$bundles): void { | ||
{% for id in entity_type_ids %} | ||
{% for bundle in infos[id]|keys %} | ||
$bundles['{{ id }}']['{{ bundle }}']['class'] = \Drupal\{{ machine_name }}\Bundle\{{ id }}\{{ bundle|camelize }}::class; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default PHPCS lints will want this moved into a use statement. Given that it can also automatically fix the lint, I'd say no change is warranted here.
@weitzman I think this command should generate classes for just one entity type at a time and I would let user to specify a bundle. |
Also I think generating abstract class should be optional. For instance, for custom entities there is no point to have a base bundle class as everything can be implemented in entity class. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/Bundle
How about src/Entity
or src/Entity/Bundle
? Though, I am not sure which path is better.
Aren't bundle classes only applicable to content entity types? |
|
I am now only showing content entities (OP is updated), and I added the option to skip base class. Update: I am now using |
I know that's tricky. The current approach is just generate a second instance of the hook and let user to merge it manually. That's how it works in |
Double printing the alter hook sounds reasonable to me ... I think I've responded to all your feedback except for allowing for bundle(s) to be specified. Should be simple. |
I've just pushed it to DCG 2.x. Output
Feel free to submit bug reports and improvements. Thank you! |
/** | ||
* A bundle class for {{ entity_type_id }} entities. | ||
*/ | ||
class {{ bundle_class }} extends {{ parent_class|split('\\')|last }} { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, we should encourage bundle classes to implement bundle interfaces. A Page
bundle class could implement PageInterface
. This is very useful, as a bundle class can implement multiple interfaces:
interface PageInterface {
public function getContent();
}
interface ArchivableInterface {
public function getArchivedDate();
}
class Page implements PageInterface, ArchivableInterface {
}
also this allows to do some more semantically checks:
if ($node instanceof PageInterface) {...}
hook_entity_bundle_info_alter
implementationDemo
node,media
generation looks like, on the CLITodo