[Framework-Team] Re: first comments on plip 148 (moving to CMF 2.1)

[Raphael Ritz]

Hanno Schlichting schrieb:
> Hello from the St. Augustin sprint :)
>
>   
cheers from Berlin to all of you ;-)
(I wish I could be there ...)
> [..]
>>    - Is it really necessary for AT/ATCT to still use the deprecated
>>      "manage_*" hooks instead of proper event subscribers?
>>      If the plan really is to also support Zope 2.11 with Plone 3.0
>>      this will cause trouble.
>>     
> This is related to the biggest TODO item that I wasn't able to solve.
> While I tried to convert at least all cataloging infrastructure in
> Archetypes (and ATCT) to use events, I failed miserably on it and didn't
> have any time to look into this again. The current state is IMO not
> acceptable as it uses an ugly trick to not catalog items multiple times,
> which is to check if an object is already cataloged before indexing it
> and if it is still in the catalog before unindexing it. You can see
> behavior in the reindexing tests in Archetypes, where quite a few new
> indexing calls happen.
>
>   
so who do we ask to take a look? Ben, Kapil, Sidnei, ...

[..]
>>    - /extra2/Zope-2.10.0-b2/lib/python/zope/tal/talinterpreter.py:754:
>>      DeprecationWarning:*** *** Insertion of non-unicode non-ascii text
>>      in TAL is deprecated and will be broken in Plone 4.0 !!!
>> [..]
>>     
> You might have noticed that I put quite some ugly patches into Plone
> trunk to deal with our mixed encoding situation. These patch into the
> guts of the Zope3 tal machinery, as it was the only way to get non-ascii
> characters working again right now.
>
>   
OK, better working with a warning than not working at all

> The ideal solution is of course to change our complete software stack to
> use Unicode internally, but the problems here are quite enourmnous.
> After talking to Martijn Faassen who was responsible for the move of
> Silva to use Unicode and has therefor quite some hands-on experience I
> did agree with him that this move probably will take at least two to
> three releases before we have changed all code to work in a pure Unicode
> environment only. I think our strategy to the Unicode battle deserves
> some extra thread and I'll post my current plan later today.
>   
looking forward to that
>>  What would be really nice to have for our add-on developers:
>>
>>    - a hands-on, fool-proof guide on how to update 3rd-party products
>>      for Plone 3.0. In particular this should contain (pointers to)
>>      instructions on supporting and using GenericSetup and the new
>>      style action handling. I'm sure Hanno has gained much experience
>>      on this by doing it for Plone/AT/ATCT so he should be in an
>>      excellent position to sum that up ;-)
>>     
> I'm sure I can write something up here, especially the common pitfalls I
> encountered. Luckily it's not too many changes but writing a product
> that works with both old-style and new-style actions is probably not an
> easy task or not possible at all.
>   
Not sure it makes much sense to require both.
Old-style actions have been deprecated since CMF 1.5 I think.

>>    - An just in passing: is there really no sane way to fix
>>      'installTypes' from Archetypes.Extensions.utils?
>>      This will break **a lot** of 3rd-party products!
>>     
> I'm sure there is a way, I just didn't have time to fix it. Help is
> welcome as always ;)
>   
OK, I might take a look at this one myself.

I just find it somewhat funny that Plone 2.5 - which was advertized
as a "framework release" - didn't require much from add-on authors
to deal with while 3.0 - advertized as a "UI release" - looks like it
it's causing quite a change ...


>>  Somewhat off topic here:
>>
>>    - there is actually one issue that worries me quite a bit at the
>>      moment but I don't think it has anything particular to do with this
>>      Plip. To see what I mean, install the plip bundle (or the current
>>      Plone dev bundle), make a plone site, visit it in ZMI, go to
>>      portal_skins, select a template like 'main_template',
>>      'prefs_install_products_form', 'table_view', or 'atct_topic_view'.
>>      Note the error when trying to 'customize' one of these::
>>
>>         Macro expansion failed
>>         exceptions.KeyError: 'scripts'
>>
>>      It does not happen for all templates but I'm sure more are
>>      affected by this. I have not been able to debug this yet but
>>      I assume at the moment that this is due to Zope 2 switching to
>>      the Zope 3 TAL engine. Others please correct me if I'm wrong.
>>     
> This sounds like a bad interaction of the CMF Python Scripts with the
> new Zope3 machinery.
No, not Python scripts, they seem to be fine.

It's the templates that show this error. Not all (e.g., portlet_events'
is fine) but some "plain" ZPTs like AT's 'base_view' in addition to
those already mentioned. But also controller page templates.
It's obviously the macro expansion that fails.
Most of time (from my random sampling) with "KeyError: 'scripts'"
but sometimes with "KeyError: 'macro'" (e.g. for AT's base_edit)

One further thing I noticed: in a CMFDefault site I wasn't able to
reproduce this error. There 'main_template' can be customized while
Plone's main_template fails with KeyError: 'scripts'

My gutt feeling says this might have something to do with including
JavaScript (any chance things might have changed here?)

> [..]
>   
>>  Summary for now: I think it is no question that this PLIP has to be
>>  accepted as otherwise we would not catch up with our underlying
>>  framework (the CMF). I consider it ready for merge as soon as there
>>  is enough confidence in a 2.1 release of the CMF itself (at least an
>>  alpha out). The only open question I see is whether we really want to
>>  make PIL a hard dependency.
>>     
> Actually I think unless we have fixed the Archetypes event story at
> least to an somewhat acceptable state, this PLIP should not be merged.
> We need to begin to switch to an event infrastructure now 
but that's the whole point: we need at least to begin with this switch 
*now*.
Meaning the longer we wait, then harder it will become.

> and issue
> meaningful deprecation warnings to add-on product developers about the
> removal of the manage* methods. The general deprecation warnings that
> manage* methods in general are deprecated aren't helpful IMO.
> Additionally we might begin to lobby for an extended deprecation period
> for the manage* methods 
not sure this will help us a lot here.
 From what I understand this is more or less an all-or-nothing thing.

Keep up the good work!

    Raphael

> as we won't be able to migrate all our stack to
> use events instead in time, especially if we want to have the option of
> supporting Zope 2.11 (which hopefully support ZODB blobs) for Plone 3.0.
>
> Hanno
>