-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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 possibility to pass custom widget with editor configuration through widget attribute on RichTextField and RichTextBlock #2175
Conversation
…nted editor configuration
@@ -262,7 +262,8 @@ def get_searchable_content(self, value): | |||
|
|||
class RichTextBlock(FieldBlock): | |||
|
|||
def __init__(self, required=True, help_text=None, **kwargs): | |||
def __init__(self, required=True, help_text=None, widget=None, **kwargs): | |||
self.widget = widget |
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.
I think would be better to set all field options to self.field_options
(as already done with help_text
and required
).
If you decided to do so, field
method can look similar to this:
@cached_property
def field(self):
field_options = self.field_options.copy()
if 'widget' not in field_options:
from wagtail.wagtailcore.fields import RichTextArea
field_options.update({
'widget': RichTextArea
})
return forms.CharField(**field_options)
Another good solution is set all field options to properties in RichTextBlock
, but this is not widely used in Wagtail: as I see only ChooserBlock
done this way. If you decided to go this way, you can deal with widget like this done in Django. Refs:
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.
Second solution is for fields, but we can apply same idea for blocks.
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.
I agree with your first proposed approach, this pattern is used mostly throughout other specific block types and upholding this consistency makes most sense to me.
As to your proposed solution, I'd prefer using the standard get method of the dictionary. This better covers all cases of a non existing key as well as an existing key returning None. The naming conventions in the below code now also follows used patterns.
def field(self):
field_kwargs = self.field_options.copy()
# check if a custom widget has been set or use default
if not field_kwargs.get('widget'):
from wagtail.wagtailcore.fields import RichTextArea
field_kwargs.update({'widget': RichTextArea})
return forms.CharField(**field_kwargs)
I've update the branch with this solution. I'm happy for your feedback if you see room for improvements.
Could you, please, check in tests also following:
|
@HitDaCa, if you need any assistance with this PR, feel free to let me know. |
@m1kola, thanks for all the feedback! I'll read through each of your suggestions in detail tomorrow morning and give my thoughts on every point. Thanks. |
…grated custom editor config override
…r RichTextBlock.field
Guys, thanks to all of you for putting in the work on this. It looks like a really valuable addition, and i'm excited to use it! |
This is really neat! Unfortunately I've encountered a snag - passing a I'm not sure what the best remedy is here. We could of course go back to the original plan of passing the |
Having thought about this some more, I've reached the conclusion that, whatever the parameter to
I think the answer is for the parameter to define a list of "features" - things that this particular rich text field is allowed to contain, such as paragraphs, bold, italics, other inline markup such as
(In practice we'd probably want a site-wide common set of features - or perhaps several standard 'palettes', for different use-cases - and a mechanism for adding/subtracting from that list on a per-field basis, like The key distinction here is that we're saying "here are some conditions that the data must conform to" (and can potentially enforce that at the whitelisting/validation stage), not "this is how rich text widget X should behave". It's up to each rich text backend to look at the feature list and configure itself accordingly (adding/removing toolbar buttons, or whatever) to present that feature set to the user as best it can. Different rich text backends will have different capabilities, of course, and that's fine - it's up to the developer to ensure that they've set up a rich text backend that actually supports the features they've specified. For example, if a field is defined as There's a lot more thinking to be done to define what a 'feature' is here - it's not enough to just come up with a standard list of identifiers and expect each rich text backend to know what they mean, because that would result in massive duplication of code (e.g. each backend has to know that 'doc-link' involves launching
As I say - needs more thinking... |
It's 4 months since last activity. Will the feature of having RichTextField-specific options eventually reach release? TYIA |
Hey @kunambi, Dave and Josh were working on this while employed with me at Springload and have both moved on to other jobs since then. @gasman has expressed reserves with the current approach, so there needs to be more work on the PR, but no one has intentions to do this work as far as I know. I will close this PR, should someone want to take it from there they should make a new one and address the feedback above. Finally, if you're interested in rich text configuration Springload has been working on a new text editor that solves this use case for us. It's not as well documented, or stable, as I'd like it to be but we do already use it on production projects. Check out https://github.com/springload/wagtaildraftail, and #2409. |
Now implemented (with an editor-agnostic |
This pull requests replaces the original pull request #2139. I had wrongly rebased to latest master before adding later changes which made code compare unusable (trying to remove rebase closed the original request).
Following the advice from @m1kola & @JoshBarr #2139 (comment), RichtTextFields and StreamField RichTextBlocks now accept a widget attribute. By default, if none is passed, the standard RichTextArea widget is used.
Following @JoshBarr comment about easily configuring various RichText widgets in future, I have also moved the immutable parts of the RichTextArea into it's own abstract base class. This allows easier creation of future RichTextWidget variations.
I have also updated the RichTextField documentation and RichTextBlock documentation to explain this new attribute addition.
I have added a test for the new attribute.