[Framework-Team] wicked integration w/ plone 3

[whit]

Martin Aspeli wrote:
> Whit,
>
> You rock. :)
>
thanks! :)
> Will skim through the code today, but I'm very optimistic that we
> should merge during the weekend.
>
> I don't think having TTW configuration for which *fields* should get
> the Wicked treatment makes much sense (too low level). 
TTW would be really hard at this point since schemas are not really 
persistent objects. as neat as it would be, I don't think this will 
really be possible until we get to persistent z3 schemas.
> Having a way to
> turn the behaviour on/off and possibly change the syntax choice makes
> sense.
>
that's what I'm angling towards.

> But then what happens with documents using the "old" syntax? Maybe it
> can be a multi-select rather than single select, so you get:
>
> Wicked syntax:
>
> [x] Wicked style ((words))
> [ ] MediaWiki style [[words]]
>
> And if you untick both, you get no wicked at all?
>
My thinking is similar, but with radio buttons: off, (()), [[]] .  If we 
want to support [[]] and (()) at the same time, I would add another 
choice(basically another regex).  At an infrastructure level, I thought 
about making multi regexes possible as solutions, but it was simpler not 
too and still easy to give the option.  

At a higher level multiple regexes could create a usability issue of 
having multiple syntax globally(more things for a user to remember).   
By making free for all linking an explicit choice, site admin might 
think more about it(or at least it's easier to describe why you wouldn't 
actually want to do this in the interface).

"off" gives you no wicked.  at some point, we might want to offer 
"freeze" (no new parsing of wicked links), and a way to turn wicked off 
and make the links permanent.  Until then, there will be the potential 
for inactive wicked (([[rubbish]]))  littering documents after it's been 
turned off.

> In any case, I say we enable by default for documents and people can
> turn on for other things if need be. A slightly more ambitious
> configuration solution would be that you have some vocabulary
> (probably a utility vocabulary with a small utility for each possible
> content type) that marks which content types can support wiki syntax
> (the exact fields to use may be properties of the utility or set in
> ZCML somewhere), and then you get another multi-select:
>
> Wicked types:
>
> [ ] News Item
> [ ] Event
> [x] Document
this will probably require some modification to ATCT (I chose not to do 
that this time) or at least some new registration schemes(instead of 
registering the content interface to IAmWicked, it would go straight to 
IATCTNewsItem).  entry points look like a nice and easy way to build the 
vocabularies and handling the registering and unregistering since they 
are orthogonal to zcml and 3rd party folks can easily add their custom 
content to the interface.  

does anyone have a good formlib example for a controlpanel that 
*doesn't* edit a cmf tool?
>
> If for 3.0 we only get it on documents (but third parties can mark
> whatever fields in their own ZCML) I don't think that's a great loss,
> though.
>
cool!

-w
>
> On 1/5/07, whit <d.w.morriss at gmail.com> wrote:
>> initially seems to be working using ATDocument unaltered(no special
>> fields, no special content).
>>
>> I need to do a bit more testing, but wicked's tests run against ATCT
>> without issue(in 3 flavors: wicked for all AT text fields, just primary
>> textfield for newsitem, event and document and document only).
>>
>> see:
>> http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/wicked/plone/ 
>>
>>
>> what fields get the wicked treatment is current determined in zcml(the
>> zcml marks the specific fields to enact behavior therefore has to happen
>> act configuration time rather than via persistent component).
>>
>> This provides some flexibility, but later we may want to mark the fields
>> more explicitly(say, in the content class itself).   I chose the 3
>> configuration options above mainly to cess out possible problems; I
>> imagine we would decide on a configuration to ship plone with, and then
>> the intrepid could twiddle the zcml if they so desired.
>>
>> Probably document-only.zcml would be the best default.
>>
>> that leaves the controlpanel...which is about a third done...
>>
>> night,
>>
>> -w
>>
>>
>>
>>
>>
>> _______________________________________________
>> Framework-Team mailing list
>> Framework-Team at lists.plone.org
>> http://lists.plone.org/mailman/listinfo/framework-team
>>
>>
>>
>>
>

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