[Framework-Team] Re: wicked stuff

[Martin Aspeli]

Hi Whit,

>> In the interest of getting releases out ... do you have any comment on 
>> https://dev.plone.org/plone/ticket/6284?

> a couple(nouri looked at this a while a back and I've been playing with 
> it yesterday and today).

Thanks for being so quick. :)

> Technical comments::
> 
> I hacked together something that should work afaict, except I get 
> non-deterministic traversal errors for the portal_factory in the tests::
> 
> excerpt:
>         new_content = 
> self.context.restrictedTraverse('portal_factory/%s/%s' % (type_name, id_))
>       File 
> "/Users/whit/dev/env/p3/src/ploneout/parts/zope2/lib/python/OFS/Traversable.py", 
> line 301, in restrictedTraverse
>         return self.unrestrictedTraverse(path, default, restricted=True)
>       File 
> "/Users/whit/dev/env/p3/src/ploneout/parts/zope2/lib/python/OFS/Traversable.py", 
> line 269, in unrestrictedTraverse
>         raise e
>     KeyError: 'ATContentTypes Topic: Add ATBooleanCriterion'

Mep :-(

> And in the browser, ArchivistUnregisteredError for the piece of content 
> I'm trying to edit.  Nouri reported issues with the creation of the  
> backlink (at) references; not sure if I got that far.

Weird.

> I checked in a drop-in replacement view that would use PF for content 
> creation, so maybe someone with more pf foo can figure this one out: 
> http://tinyurl.com/yvm8fd. 
> 
> You can activate it by uncommenting this reg: http://tinyurl.com/2dkz5x 
> (and of course commenting the corresponding one).

All I could suggest is to mimic what createObject.py does, but 
portal_factory is never fun.

> Less Technical::
> 
> (why I'm less than motivated to invest more time in pursuing #6284)
> 
> 1. the general wiki usage pattern and the plone security model make the 
> possibility of creation of unwanted content rather low.  Most people use 
> wiki links to rapidly layout a set of pages they want created whether 
> they follow the links or not.  Creating empty pages in a wiki is 
> creating a structure (content with ids and titles) to be filled in 
> rather in contrast to the the result of random clicking of an add item 
> button or menu and creating a un-titled, id-less document.

True - we don't get ghost objects with ugly ids and empty titles since 
Wicked pre-fills those.

> 2. After running wicked at opencore for almost 2 years, we've never had 
> a complaint or issue with this.  It may be slightly "bad form" but 
> pragmatically, I not sold that it's worth the time mucking with pf.

I'd tend to agree if it's going to be really hard.

> 3. inline adding via kss (or proper addviews for plone and/or at) are 
> probably the next step for wicked links, making this pf dance irrelevant 
> in the future.

+1 on both counts

> I also added multiple pattern support( ie [[]] or (()) ).  Whichever 
> pattern matches first is used for the whole block of text.  I'm not sure 
> this is the preferred behavior, but it was much faster to implement(and 
> the code is easier to read than the regexes).  Perhaps someone knows an 
> alternating regex that will work with the existing code.
> 
> some variations that did not:
> 
> \(\(([\w\W]+?)\)\)|\[\[([\w\W]+?)\]\]
> 
> [\[\(][\[\(]([\w\W]+?)[\)\]][\)\]]
> 
> (?:\[\[)|(?:\(\()([\w\W]+?)(?:\)\))|(?:\]\])

That's possibly the worst regexps I've ever seen :)

I'd suggest that we leave this issue open but downgrade. Arguably, it 
should never have been critical in the first place.

Martin

-- 
Acquisition is a jealous mistress