[Framework-Team] Re: Re: wicked integration w/ plone 3
On Mon, 08 Jan 2007 08:35:18 -0800, whit <[EMAIL PROTECTED]> wrote: Martin Aspeli wrote: On 1/8/07, whit <[EMAIL PROTECTED]> wrote: [ ] enable wiki [ ] use media wiki syntax <- enabled types -> Event Page News Why do we need both an "enable wiki" option and a list of enabled types? If all the types are deselected, wiki syntax is off by definition, no? yeah, I just did it to be explicit and so everything could be turned off in one click. should I pare it down to types and the media wiki toggle? No need to spend too much time on it as long as the info is in there. The wiki stuff shouldn't be a separate control panel, but be part of the types control panel (just like Tom's new markup support). As long as we have enough code to infer how to set things on and off, we should be able to stick this into a formlib-powered version of the types panel. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: wicked integration w/ plone 3
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
[Framework-Team] Re: Re: wicked integration w/ plone 3
On Fri, 05 Jan 2007 10:57:34 -0800, whit <[EMAIL PROTECTED]> wrote: Raphael Ritz wrote: What I would like to see in addition (but I admit that it's too late to asked for that now) is a way to offer the (power) user to specify the content type to be created on add. Something like (in the context of a page): ... as outlined in the [[Plone UI Sprint Announcement]][News Item] our next meeting will be focusing on UI (more details on the [[Plone UI Sprint]][Event] calendar entry) ... would then generate a 'News Item' and an 'Event' entry respectively. I guess mediawiki doesn't really have a concept of "content types". the syntax extension we've been talking about at openplans is similar, but has a more open ended application. It might work sort of like this: ((Link text || content-type )) # just create a content type I'm reluctant to add too much syntax beyond basic linking. What I'd prefer in the content type use case is that the link to create a new page goes to folder_factories (which I will fix for Plone 3.0, I promise ;) and some Ajax pulldown variant for those with JS — which allows you to select which type you want. If (for instance) Page is the only allowed content type in the location you're in, this intermediate step will not be there, obviously. In general, the UI that indicates that you can create a new page needs some love. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
