agree on and document a naming convention for plugin models and classes
See original GitHub issueEspecially for beginners it can be very confusing if the plugin model and the plugin base have the same name. And problems like http://stackoverflow.com/questions/20334029/django-app-cannot-assign-imagetext-link-must-be-a-link-instance arise, which could be avoided if we have one naming standard. Since we don’t have a recommended, documented way of doing things there are all sorts of variations out in the wild.
Naming proposition
Plugin Models (models.py
):
from cms.models import CMSPlugin
class TextPlugin(CMSPlugin):
title = models.CharField(max_length=255)
body = models.TextField(blank=True, default='')
Plugins (cms_plugins.py
):
from cms.plugin_base import CMSPluginBase
class Text(CMSPluginBase):
model = TextPlugin
render_template = '....'
Issue Analytics
- State:
- Created 9 years ago
- Comments:27 (24 by maintainers)
Top Results From Across the Web
typescript-eslint/naming-convention.md at main - GitHub
Enforcing naming conventions helps keep the codebase consistent, and reduces overhead when thinking about how to name a variable.
Read more >Magento Certification: Class Naming Conventions | BelVG Blog
This time our developer will tell you about class naming conventions and their relationship with the autoloader.
Read more >Naming guidelines for extensions - Dynamics 365
This article describes the naming guidelines for extensions. Artifacts must have a name that is unique across all models at installation ...
Read more >Magento 2 best practice for class locations and names
How to determine the construction of the class name and location, a folder at the root of the module, in Model, in Helper,...
Read more >Learn SQL: Naming Conventions - SQLShack
A naming convention is a set of unwritten rules you should use if you want to increase the readability of the whole data...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hey,
I checked our code base and we use
MyPlugin
andMyPluginModel
for the plugin and it’s plugin model respectively. It may not be too beautiful, but it is clear what is meant when you are talking about the concepts of plugin and plugin model which where introduced and will likely stick around. So for anyone who does not know the documentation by heart it is impossible to deduce whether the CMS prefix is identifying the plugin or it’s model. So for the sake of simplicity and clarity I would prefer thePlugin
andPluginModel
suffixes over any other. Think of all the time and pain saved for sacrificing the a-model-suffix-is-not-beautiful argument.My two cents
Jakob
This will now be closed due to inactivity, but feel free to reopen it.