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

2007-01-07 Thread whit
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

2007-01-07 Thread Alexander Limi
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

2007-01-07 Thread whit
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

2007-01-07 Thread whit
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

2007-01-07 Thread Alexander Limi
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

2007-01-07 Thread Martin Aspeli

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

2007-01-07 Thread Alexander Limi
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