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 type.

I think it should be on for everything we ship that has a Rich Text
field.

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 /
IPrimaryField).

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 DC:Description.

--
Alexander Limi · http://limi.net


_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to