On Fri, 05 Jan 2007 14:42:46 -0800, whit
<[EMAIL PROTECTED]> wrote:
Usually, per-content-type settings is the best combination of
flexibility and combinatorial explosions. ;)
are those the good kind or bad kind? per content type is probably pretty
easy, I since I'm guessing each ATCT content type has a uniqueish iface.
s/combination of/compromise between/
I think per-type is the best choice by default.
anyway, let make sure I have this right. Do we want to allow people to
choose both [] and (()) globally? or just one or the other? both seems
silly to me, but that's just my gut.
My opinion is that people won't need to disable one or the other — either
you need/want wiki syntax, or you don't. Of course, providing a switch
somewhere on the FS or somewhere in the ZMI to do this is fine, I just
don't think the average Plone user will have this need at all, and it
makes the UI much much simpler if wiki support is a simple on/off on the
I think it should be on for everything we ship that has a Rich Text
interesting. turning on all textfields is easily done but I'll have to
think a bit on how to blacklist fields and content types(the approach
above sort of takes care of this, though I'm starting to see a need for
schema unique interfaces for the actual field ala IDescription /
Also worth considering, description is frequently a TextField and
frequently rendered from catalog metadata. is that an acceptable
incongruity? this could change when wicked's cacheing moves to being
utility driven rather than annotation(and cache access no longer depends
on having the context in hand).
I said Rich Text fields, not normal text fields like Description. :)
Anything that gets a Kupu field at the moment, in other words.
There shouldn't be any metadata, markup or anything like that in the
Alexander Limi · http://limi.net
Framework-Team mailing list