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 [EMAIL PROTECTED] 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@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
