[Framework-Team] Re: wicked integration w/ plone 3

[whit]

Alexander Limi wrote:
>
>
> On Fri, 05 Jan 2007 10:57:34 -0800, whit 
> <d.w.morriss-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> 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.
understandably.  I think in situations people will really want this(like 
at topp), but that doesn't mean it makes sense to ship with it or focus 
on it.  see comments at bottom.
>
> 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.

+100 to that. been longing for this for a while ;)
> 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. :)

in general,  I think concepts like syntax extension are probably best 
handled by thirdparty libs(or shippable as options to be activated via 
zcml).   this way, it's easy to warn people of the potential effects on 
performance or usability...no pointy clicky road to hell. 

This is sort of where setuptools dovetails very nicely with zope3; it's 
easy to generate vocabularies based on entry points that handle the 
component registration code. Folks can extend your ui with no bad 
touching, CMFQi madness, or commit rights.  I'm very happy about how 
easy this is to extend without invasion and how easy it is to add 
options rather than shoving features down peoples throats. 

well it looks like it'll be pretty easy... still have to finish writing 
it ;) 

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: whit.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20070105/d6b16c59/attachment.vcf>