Skip to content
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

In the XML plugin loader allow a parent plugin that can contain core settings for many within a group #272

Open
davetcc opened this issue Jan 2, 2023 · 0 comments

Comments

@davetcc
Copy link
Owner

davetcc commented Jan 2, 2023

Provide support for a parent plugin that has all its values applied alongside the actual plugin. For example, if we look at themes, the exact same logic is applied across at least 6 files, for displays the same logic is applied to a greater and lesser extent across many of the plugins too. In fact, there is an amount of duplication in many of the plugins.

I propose the simplest solution to start with that would provide a new optional element at the top level called parent, it would hold the name of a plugin template from the templates directory. This would ensure anyone looking at the plugin structure would not mistake a template for a plugin. It would in every other way be a plugin. Maybe a rule would be that it had to end with Template, eg it would be in templates/ColorThemeTemplate.xml to ensure it is not mistaken.

  • During the loading, the top level fields SupportedPlatforms, Description, Documentation, RequiredLibraries, ImageFile would all be ignored. They make no sense in the plugin context and should just be used to document how the template can be used.
  • The properties are to be additive, IE the list of properties becomes parentProperties + leafProperties.
  • Any applicabilityDefs will be added to the list of applicabilities.
  • Any source files will be added to the list of source files, as will any replacements, they will all be global
  • Any include files will added to the list of include files. To ensure order, use priority, do not rely on ordering
  • Global variables will be defined parent first, then plugin.
  • Functions, like plugins will appear in the source parent first, then plugin.

Theme plugins could be halved in size, and others could be significantly simplified and duplication reduced.

With this a hypothetical theme plugin may look like:

images/
   theme1.png
templates/
   CoreTemplate.xml
theme1files/
   files-for-theme-1
theme2files/
   files-for-theme2
theme2.xml
theme1.xml (references CoreTemplate.xml)
tcmenu-plugin.xml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant