Thanks James Bennett for the thoughtful reply, it sounds like the general
consensus is that the choices feature truly is something that the majority
of users wouldn't want (and I'm inclined to defer to the wisdom of Marty and
James B. -- if you guys think it is mostly useless I'll accept that
parti
I certainly wasn't trying to come off as against any suggested improvements
and apologize if I seemed so. I originally thought that the suggestion was
to drop the option of selecting a markup type in favor of a callable or
perhaps just saw the two as incompatible for some reason.
I wonder if perh
To me there are a few big problems with the markup_func proposal as I see
it:
* it removes the ability to provide multiple markup_types on a given field
* what is unpythonic about taking in two extra parameters to customize the
field?
My goal here isn't to provide a generic "accepts-any-markup" f
I've updated my patch with a way to pass extra options to markdown/
docutils/textile that should handle any of the common cases. I've
also moved render_markup into the class so that it is possible to
override on an inherited class.
> First, I don't think you actually addressed the question men
Limberg wrote:
> On Sun, Feb 22, 2009 at 4:46 PM, James Turk wrote:
>
> > What about other types of markup?
> > Some have suggested supporting more types of markup but to me this
> > seems outside the scope of contrib.markup which currently only
> > supports ReST, markd
I've needed a model that stored the markup/markup_type/rendered-markup
several times and typically just made those fields manually, but just
recently when working on a few projects that all needed this behavior
I decided to wrap up this behavior as a MarkupField and post it on
django snippets (htt
Quite understandable that this isn't a priority by any means, ticket
including patch is up here for posterity:
http://code.djangoproject.com/ticket/8447
On Aug 20, 9:20 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 20, 2008 at 8:08 AM, Malcolm Tredinnick<[EMAIL PROTECTED]> wrote:
>
I've been trying to stay up to date when testing locally and just
noticed 8399 seems to be the source of a break in my code where
MultiValueDict's iteritems was used. I see that this relates to
http://code.djangoproject.com/ticket/7331 and I understand a decision
had to be made.
iteritems used t
