Re: [Framework-Team] Re: wicked integration w/ plone 3
the old stuff has been reviewed but the new stuff should be looked over too. banging on the controlpanel right now(wrote the code, still need to test).The rough and ready choices are the following:: [ ] enable wiki [ ] use media wiki syntax <- enabled types -> Event Page News -w Alexander Limi wrote: On Sun, 07 Jan 2007 20:23:13 -0800, whit <[EMAIL PROTECTED]> wrote: alright, I shuffled around the registrations so Document, Event, and NewItem can be registered individually. I scratched the entry point stuff since we really don't have an egg story yet(and entry points are invisible if a distribution isn't actually installed in some fashion...oh well, maybe next time) All the tests for wicked and plone are passing. have got about 45mins now to try to kick out a basic interface for the controlpanel. the merge is going to be basically 1 line of zcml, including the py code in wicked and whatever I get done with the controlpanel. Do you want me to cut a bundle/branch for this, or just commit to trunk with the zcml commented out? I don't think a branch as such is required, but whatever is going to ship with Plone should be reviewed by a member of the FW team. I can't remember if anybody reviewed Wicked yet? :) --Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield org:The Open Planning Project;OpenPlans adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA email;internet:[EMAIL PROTECTED] title:Lead Developer tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: wicked integration w/ plone 3
On Sun, 07 Jan 2007 20:23:13 -0800, whit <[EMAIL PROTECTED]> wrote: alright, I shuffled around the registrations so Document, Event, and NewItem can be registered individually. I scratched the entry point stuff since we really don't have an egg story yet(and entry points are invisible if a distribution isn't actually installed in some fashion...oh well, maybe next time) All the tests for wicked and plone are passing. have got about 45mins now to try to kick out a basic interface for the controlpanel. the merge is going to be basically 1 line of zcml, including the py code in wicked and whatever I get done with the controlpanel. Do you want me to cut a bundle/branch for this, or just commit to trunk with the zcml commented out? I don't think a branch as such is required, but whatever is going to ship with Plone should be reviewed by a member of the FW team. I can't remember if anybody reviewed Wicked yet? :) -- 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: wicked integration w/ plone 3
I should ammend previous email to say... I see a couple broken tests in plone, but they don't appear to have anything to do with wicked on the surface. -w ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: wicked integration w/ plone 3
alright, I shuffled around the registrations so Document, Event, and NewItem can be registered individually. I scratched the entry point stuff since we really don't have an egg story yet(and entry points are invisible if a distribution isn't actually installed in some fashion...oh well, maybe next time) All the tests for wicked and plone are passing. have got about 45mins now to try to kick out a basic interface for the controlpanel. the merge is going to be basically 1 line of zcml, including the py code in wicked and whatever I get done with the controlpanel. Do you want me to cut a bundle/branch for this, or just commit to trunk with the zcml commented out? -w ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: wicked integration w/ plone 3
On Sun, 07 Jan 2007 14:18:04 -0800, Martin Aspeli <[EMAIL PROTECTED]> wrote: Again, I'm not sure if you agree or not, Alex, but IMHO we should do this on any RichTextField in *ATContentTypes*, but not hack it into every RichTextField for *all* Archetypes content types (i.e. third party ones). Oh, absolutely. -- 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: wicked integration w/ plone 3
Alexander Limi wrote: 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. Again, I'm not sure if you agree or not, Alex, but IMHO we should do this on any RichTextField in *ATContentTypes*, but not hack it into every RichTextField for *all* Archetypes content types (i.e. third party ones). Martin ___ 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
