Opened 16 years ago
Closed 12 years ago
#10317 closed New feature (wontfix)
New Feature: django.contrib.markup.fields.MarkupField
Reported by: | James Turk | Owned by: | James Turk |
---|---|---|---|
Component: | contrib.markup | Version: | dev |
Severity: | Normal | Keywords: | markup forms |
Cc: | Carl Meyer | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
I recently published a snippet of something I've wanted in Django for a long time, a MarkupField that handles conversion to HTML on save and an accessor that calls mark_safe.
My implementation is at http://www.djangosnippets.org/snippets/1332/ (Credit where credit is due, I also borrowed the method of detecting which markup libraries are installed from a slightly less featured version http://www.djangosnippets.org/snippets/1169/)
Jacob commented on Twitter that he'd like to see this as well and to submit a ticket.
I'll put together the appropriate fields.py / documentation / tests and should have a candidate patch up soon.
Attachments (1)
Change History (16)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
follow-up: 4 comment:3 by , 16 years ago
One thing I don't like about that implementation is the need to have several attributes on the model, just having a complex obj that stored all of them on 1 attr would be preferable I think.
comment:4 by , 16 years ago
dc & Alex: I've replied to your critiques and opened up discussion on django-developers: http://groups.google.com/group/django-developers/browse_thread/thread/c9124d565c17f972
by , 16 years ago
Attachment: | markupfield-with-docs.diff added |
---|
markupfield implementation and markup docs changes (now with extra options)
comment:5 by , 16 years ago
Has patch: | set |
---|---|
Needs tests: | set |
comment:7 by , 16 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:8 by , 16 years ago
Cc: | added |
---|
comment:9 by , 15 years ago
I am now maintaining django-markupfield in a github repository at http://github.com/jamesturk/django-markupfield/ it is not the exact version debated on the list as I personally did not find that useful (though I do see how this version is too special of a case to fit into django core)
Should the design decision on this come down in favor of something akin to what I am now maintaining externally I would be more than happy to do the integration necessary to produce a patch that moves MarkupField into django.contrib.markup
comment:10 by , 15 years ago
I forgot about this during 1.2 feature proposal, but FWIW I have a fork of James' repo which I've simplified/modified to more or less match the API outlined by James and others in the django-dev thread. I'm using it happily as an external app and don't have any particular itch to see it in core, but if a MarkupField is wanted in core I'd be happy to transform it into a patch and make any needed changes.
comment:11 by , 15 years ago
Um, yeah. The first James there is James Turk, the second is James Bennett. Disambiguation FTW.
comment:12 by , 14 years ago
Component: | Contrib apps → contrib.markup |
---|
comment:13 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:14 by , 13 years ago
Easy pickings: | unset |
---|---|
Needs documentation: | set |
Patch needs improvement: | set |
Triage Stage: | Design decision needed → Accepted |
UI/UX: | unset |
This has been stuck in DDN for a long time. It's a small amount of code and it would be a reasonable addition to django.contrib.markup.
comment:15 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
contrib.markup has been deprecated (#18504) and will be removed in Django 1.6. Closing as obsolete.
I think it must be possible to use any custom markup with this field. Maybe not hardcode markup checks but accept markup func as arg for example?