Re: [Framework-Team] Re: wicked integration w/ plone 3
On Jan 8, 2007, at 11:29 AM, Martin Aspeli wrote: On 1/8/07, whit [EMAIL PROTECTED] wrote: [ ] enable wiki [ ] use media wiki syntax - enabled types - Event Page News Why do we need both an enable wiki option and a list of enabled types? If all the types are deselected, wiki syntax is off by definition, no? plus perhaps a JS-enabled 'select all types' checkbox. also, the blacklist approach seems to lend itself here, to auto-enable new types, no? tom Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ 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
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
Re: [Framework-Team] Re: wicked integration w/ plone 3
Hi Raphael, I don't think having TTW configuration for which *fields* should get the Wicked treatment makes much sense (too low level). Agreed. But in the long run it might very well make sense. I like for instance the 'textfilter' approach and I could imagine more functionality managed that way. I think in particular of the way in which I currently support inline citations in CMFBib via PortalTransforms which sucks in that it's not really a trafo between different mime types but only fake ones. Similar for 'safe-html' or 'html-captioned'. Having these testfilter-based would be much nicer I think. Having the possibility to configure TTW (ZMI or configlet) which filters to apply for which fields - maybe even controled by conditions (e.g., safe-html filtering is skipped for content coming from trusted users to make up an example) could go a long way. I agree, but I think this would have to take the form of a well-defined Python configuration mechanism and a use-case specific UI on top of that. That is, I don't think we'd ever want to expose the user to something like: Portal type: CMFBibDoc Please tick the fields that should be wiki-like. Fields: [ ] title [ ] description [ ] body [ ] relatedItems ... Instead, we'd want to make it easy to get something like: Transformations Bibliography items: [ ] Enable wiki syntax [ ] Enable auto-citation Wicked types: [ ] News Item [ ] Event [x] Document Talking about content types: 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. Interesting idea. The problem is possibly that people may not know the full name of the content type (this is a vocabulary thing rather than a free text thing), but certainly supporting this optionally would be cool. I'd assume it wouldn't even be that hard to add (possibly at a later stage). Browsing through the code, I see that 'add_content' actually supports this but I was unable to find this in the UI. Ah, nifty. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: wicked integration w/ plone 3
Raphael Ritz wrote:
Martin Aspeli schrieb:
[..]
I don't think having TTW configuration for which *fields* should get
the Wicked treatment makes much sense (too low level).
Agreed.
But in the long run it might very well make sense.
I like for instance the 'textfilter' approach and I could
imagine more functionality managed that way. I think in particular
of the way in which I currently support inline citations in CMFBib
via PortalTransforms which sucks in that it's not really a
trafo between different mime types but only fake ones.
Similar for 'safe-html' or 'html-captioned'.
Having these testfilter-based would be much nicer I think.
yay! death to txtfilter, long live txtfilter. I thought I was the only
one who cared.
this is pretty much the idea behind wicked.fieldevent[1]. txtfilter is
actually re-implemented as an example in wicked.fieldevent but it was
more efficient to register wicked directly as a subscriber to render
rather than put it into a txtfilter pipeline. If you're filters are
orthogonal(ie don't require sequential dispatch), registering them
directly as fieldevents will work quite nicely. since we can do
persistent components now, registering and unregistering the behavior
should be super easy(mainly an interface management problem)
_1:
http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/wicked/fieldevent/
Having the possibility to configure TTW (ZMI or configlet)
which filters to apply for which fields - maybe even controled
by conditions (e.g., safe-html filtering is skipped for content
coming from trusted users to make up an example) could go a long
way.
[..]
Wicked types:
[ ] News Item
[ ] Event
[x] Document
Talking about content types: 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.
Browsing through the code, I see that 'add_content' actually
supports this but I was unable to find this in the UI.
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 | Resulting Document Title or existing Document)) #
link different than title or id
((New Link Text | Old Link Text)) #
change link text
((Link text | http://externallink.com)) #
not really needed with intelligenttext
((Link Text | ../path/to/target )) #
link to a specific item, document creation or searching scope
((Link text | target specification | content-type ))#
above + contentype
((Link text || content-type )) #
just create a content type
the text filter pattern is easier to code if you have a bounded area
(though my regex foo is not enormous). for simplicity, I would prefer
to build the syntax within the (()), but what happens there(in txtfilter
speak, the chunk) could be taken as far as anyone wants to.
The best junction for this to take place is the actual fieldevent
subscriber, after wicked is initialize but before the output is
rendered. The filter object gives access to the parsed chunks and
provides a handle to the cache; simple preprocess the chunks and stick
the results in the cache.
basically this is what happens on the storage of a wicked field minus
rendering(the query algorithm on storage also are a bit more optimized
so the pattern might speed things up a bit though most of the time,
things are simply pulled from the cache).
as you pointed out, some of the infrastructure is already there. Most of
the rest is pretty fun/easy programming and put the new components
together as a base configuration option that can be chosen from the
control panel.
Anyway: +1 on the merge
Raphael
PS: could be just me but when trying to play with the review
bundle it just didn't work (complaining about a missing migration).
Also, when trying to follow the 'easy_install' suggestion that
I found somewhere I only get:
Creating /extra2/sites/testWicked/lib/python/site.py
Searching for wicked
Reading http://www.python.org/pypi/wicked/
Couldn't find index page for 'wicked' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://www.python.org/pypi/
No local packages or download links found for wicked
error: Could not find suitable distribution for
Requirement.parse('wicked')
[EMAIL PROTECTED] testWicked]$
No time to look deeper into this at the moment :-(
I need to make a new
Re: [Framework-Team] Re: wicked integration w/ plone 3
snip Interesting idea. The problem is possibly that people may not know the full name of the content type (this is a vocabulary thing rather than a free text thing), but certainly supporting this optionally would be cool. I'd assume it wouldn't even be that hard to add (possibly at a later stage). yeah, wikiwyg is one approach to this(richtext editor that spew wiki syntax). I think rapheal summed it up when he said power user; you would assume other users would probably pick this up via cut and paste. anyway, it's pretty extensible, but for plone itself, we should probably keep it super simple. (()) and [[]] are pretty readable, but I would like to emphasize any other syntax extension to be optional both to make optimal performance(since wicked does occasionally violate lurker's provision against caculation on rendering ;) ) easy to maintain and keep the user experience clean by default. fortunately, persistent components make this much easier! -w 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
Re: [Framework-Team] Re: wicked integration w/ plone 3
Alexander Limi wrote: On Fri, 05 Jan 2007 02:33:54 -0800, Martin Aspeli [EMAIL PROTECTED] wrote: I don't think having TTW configuration for which *fields* should get the Wicked treatment makes much sense (too low level). Having a way to turn the behaviour on/off and possibly change the syntax choice makes sense. 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. 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? I wouldn't even offer this. The likelihood of a document having [[]] or (()) without being a wiki page is extremely unlikely. This level of control makes no sense in the user interface, it should be reduced to a simple: [ ] Support wiki-style linking …in the content type panel. If the ability to disable selectively the [[]] or (()) syntax should be there, it should be in the configuration of the product. It's very unlikely that you want one content type to support one syntax, one the other, but none of them both different ones. (it's not a product anymore ;) 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. it's worth remembering that a formlib control panel like this could offer the options at a folder level ie the site uses (()) but individual folder use [[]]. We don't have folder controlpanel ui but it does seem useful in scenarios like this. a gestalt of marten and my suggestion is sort of the quickest way to having a control panel if not the most optimal. enabling by content type is a bit more work(not super complicated but basically a registration class for each content type). Maybe I'll do the one for document as a start. In any case, I say we enable by default for documents and people can turn on for other things if need be. I think it should be on for everything we ship that has a Rich Text field. Then you can disable it if you want. Wikis are becoming commonplace enough for people to expect that syntax to work, and it's unlikely to have false positives unless you are doing something very very specific. 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). One of the cases I could think of would be programming, things like setMethod(( blah )). Does wicked parse inside pre and code tags? currently it is not very lisp friendly. creating some mechanism for ignoring certain blocks would indeed be valuable, possible by creating a small pipeline(filter for wickedable chunks, wicked filter them, put it back together, render whole kabob). getting into xslt territory here, maybe there is stuff in deliverance that could help keep this fast. -w 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
Martin Aspeli wrote: whit wrote: does anyone have a good formlib example for a controlpanel that *doesn't* edit a cmf tool? plone.app.controlpanel has none? There are examples of formlib in plone.app.contentrules and plone.app.portlets.portlets, and Rocky has a formlib tutorial. Otherwise, Hanno may have light to shed. :) The approach I have taken in plone.app.controlpanel is to introduce a middleware-adapter for the IPloneSiteRoot that will act as the context for the formlib form. Read the full story in http://dev.plone.org/plone/browser/plone.app.controlpanel/trunk/README.txt This approach allows you to do any kind of work in the adapter. If you look at the types control panel you won't see any CMF tools usage inside there ;) Hanno ___ 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 Fri, 05 Jan 2007 17:54:36 -0800, Martin Aspeli [EMAIL PROTECTED] wrote: Emphasis on we ship. I would strongly -1 having this on for every RichField in every product (i.e. do it at the AT level), which is how I read it the first time. Doing it for Document, News Item and Event is probably sensible though. Absolutely. The point is that it will always create Documents (I assume); you won't get news items from wiki'ing news items and so on (which is probably not what you'd expect). It should give you the choice, if there are several types of content available in that location. One of the cases I could think of would be programming, things like setMethod(( blah )). Does wicked parse inside pre and code tags? Good point. We probably will find a few more of those. Even if that's pretty lame python. ;) Lame Python is what I do best, baby! -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
