-
Notifications
You must be signed in to change notification settings - Fork 83
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
Added CTYPE Registry system for content extensions by plugins. #96
base: master
Are you sure you want to change the base?
Conversation
metadata plugin for testing content modifier plugins.
I also revised metadata plugin according to changes to show how the content/modifier system works. |
Yes, it is a complete superset. I didn't even know it existed till halfway though :) I was happy to find a reference when I realized the twitter-summary-cards plugin. It is a complete superset with support for multiple twitter card types and other social media share metadata as well as SEO metadata. It also prevents exceptions like cropped description tag breaking HTML because of odd number of doublequotes inside the cropped description text.
I strongly agree with both your points. I did it that way because I thought writing a proper content modifier system would take a long time and the functionality provided by the plugin is too essential to wait. But I got comfortable with the codebase faster than I expected because it was extremely fun working on Coleslaw :D So I decided to write the system that tries to provide all the functionality that I found lacking so far in plugin system. The design actually shaped up while I was trying to figure out how to design I can finish the shouts plugin in 2 days if this PR gets accepted. @PuercoPop Your ideas about how to write the extension system helped me come up with this design btw. So thank you for discussing the possible architectures. Though instead of creating a mapping between content types and extensions, I designed the system in reverse (if I understood your proposal correctly). The one-on-one mapping between the content subclasses and file extensions stay exactly as they are. But all content modifier plugins that are enabled dynamically add themselves as superclasses to the content types they effect. So the actual hierarchy of a content class is only defined when a specific blog configuration is loaded. Each content type is a subclass of the content class, you (normally) do not subclass content subclasses to extend them, instead you add modifier classes to content class to inherit modifiers properties. I think that is kind of more suitable because there wont be a million different types of content that heavily inherit from each other but almost all modifier types will try to extend more than one content type. So far testing with several plugin types that I am writing it feels pretty elegant TBH. And it didn't really error in any case yet. Of course I didn't test it with the plugins that are not revised for the new architecture. But it takes about 2 minutes to revise an old plugin to the new system really. So I think it will not be a problem. |
@kenanb This is interesting and impressive work but it's definitely a more invasive change than the previous PR and I would feel uncomfortable merging it without some more thought. I'd also still really like to get a good test suite in place before more big changes drop in coleslaw but it's tough with teaching and the semester being in full swing. I like the idea of a We could add some sugar on to that to make sure that plugins could easily validate or ensure that all needed metadata was present on a CTYPE. Anyway, I'm not comfortable merging this right away but it is excellent food for thought. Thanks! |
@kingcons of course a simpler solution is possible for extra metadata. This PR doesn't actually try to fix that problem, it tries to fix the problems you defined in Plugin Constaints and Better Content Types section of Anyway, I totally understand you feeling uncomfortable merging it. these are big changes after all. But all plugins I write will rely on the serious changes I make to the plugin system and I really need to add this functionality to make coleslaw usable for the future projects I have. So I will have to concentrate on my fork instead of contributing to this repo. I mean my plugins will be incompatible, at least without some tweaks. I hope that is allright for you. |
@kenanb That makes perfect sense. Thanks for your efforts. Hopefully in a little while I can see how your improvements turn out and incorporate them as I'm able. :) |
So I created a complete content system layer on top of the original one. It supports:
defcontent
macro.defmodifier
macro. Content modifiers are actually classes that directly superclass the specified content types when enabled.Each content type is created using the
defcontent
interface. All content types are plugins now. Evenposts
. It is just ensured to be always loaded (even when absent from plugins list) for backwards compat.(defmacro defcontent (name indexable-p &rest body)
The following defines an
indexable
content calledpost
:The only difference from the old version is the absence of direct-superclass list and the 't' paremeter. Direct superclasses are now dynamically adjusted by the content modifiers. At least
content
class is always a superclass. The rest are added by modifiers.The bool value
t
after the class name defines if the content is indexable or not. Instances of a content type will always be shown in relevant indices when the content is set indexable. They will be hidden from indexes if indexable-p is set tonil
.Each content modifier is created using
defmodifier' interface.
(defmacro defmodifier (name ctypes direct-superclasses direct-slots &rest options)`An example modifier named
metadata
that modifiespost
,page
andshout
content types.A content modifier is defined almost the same way a class is defined except you also add the list of effected content classes immediately after the name.